Subject: [Simple] Re: [Sipping] RE: text/T140 and audio/t140 was: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Jun 2004 21:43:57 -0500

Dropped off sipping and avt and added simple mailing list...

I like this list but I think you have one other thing you want. You want to
make a protocol that actually gets build and deployed. The narrower the
market is that is addressed by your solution or as it gets more complex to
build, the less the odds are of it being build. IM is going to be build.
Session mode IM is highly likely to be build.

What would you need changed to the current requirements for session mode IM
in SIMPLE for it to meet all of your requirements? I believe there are extra
requirements, I¹m just trying to figure out what they are so perhaps we can
see if they can be addressed in IM.

Cullen

On 5/31/04 1:22 AM, "Gunnar Hellstrom" <[email-masked]> wrote:

> By this response, I include the SIPPING group in our discussion.
> So, introduction: We have created a new transport of real time text for
> character-by-character conversational use, called audio/t140c  ( in the drafts
> sofar we called it audio/t140, but in order to distinguish it more easily in
> sdp and discussions we will now propose name change to audio/t140c )
> 
> The purpose of this format is to take text reliably between two PSTN transit
> gateways when the connection is used for IP transit of PSTN calls. It is said
> to be a benefit for the big gateways if they can use the same RTP stream for
> everything - voice, text, modem, fax, DTMF.
> 
> So, this format is introduced in the revision of the rtp spec for text
> conversation rfc2793 that we are working on in avt.
> http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-04.txt
> 
> The earlier transport text/t140 is still there, and is still compatible with
> RFC2793, and is intended for both gateway and endpoint usage.
> 
> Now it turns out that some designers may have had an intention to start using
> the audio/t140c format in other applications than trunking PSTN calls,
> involving residential gateways and even SIP endpoint terminals. That caused a
> flame of discussion in avt, because that idea seems to threaten the whole idea
> of orderly service provision in SIP networks.
> 
> Such discussions are not right placed in avt. There we make the transport
> specifications and do not discuss deeply how these transports are going to be
> included in network structures, or how they go together with ambitions to
> offer ambitious new services with SIP.
> 
> The right place for the discussion may be sipping or mmusic, and also in
> external groups picking up SIP and putting profiles and usage conventions on
> it. 
> 
> We have concluded that real time text is a medium in its own right, that needs
> to be available simultaneously with voice in new networks. There is a low
> functionality implementation of text in PSTN, but we do not want its
> limitations to influence the service provision in SIP. But we want to offer
> gatewaying to it just as SIP voice telephony offers gatewaying to PSTN voice
> telephony.
> 
> The important functional goals we want to reach with text in SIP are at least
> the following: 
> 
>   1.Truly simultaneous text, voice and video.
> 
>   2. Two way simultaneous transmission with a character-by-character feeling.
> 
>   3. Internationally usable character set.
> 
>   4. Capacity for transmission as fast as text can be produced by a typer and
> an automatic voice-to-text application - 30 characters per second.
> 
>   5. Possibility to participate in managed conferences.
> 
>   6. Good reliability and indication of rare loss to the user.
> 
>   7. Good security
> 
>   8. Declaration of the intention to use text in a session, and using that
> knowledge in allocating resources for the call
> 
>   9. Declaration of preference to use text as the main medium in a call, and
> using that knowledge in routing calls.
> 
>   10. Request to invoke text <-> voice transcoding services, and routing of
> the calls properly for that.
> 
>   11. Offering text alternatives to Interactive Voice Response systems
> 
>   12. Routing of emergency calls to agents used to handling text calls.
> 
>   13. Implenmentation in most SIP devices with interoperability between them.
> 
>   14. Smooth ways to interoperate with conversational text in other networks,
> e.g. PSTN.
> 
> RFC3351 expresses some of these goals, and text is mentioned in many places in
> IETF specs. E.g. megaco requirements. rfc2793, rfc2793bis, sipping-toip,
> sdp-new-16, avt-emergency, sipdev, callee-caps, transcoding.
> 
> If text is not always declared as text in sdp, when SIP endpoints and
> residential gateways are involved in the sessions, we have little chance to
> meet all the ambitions. That is the threat we see when designers coming from
> the voice side start to think that they can use audio/t140c outside its
> original application in the big trunking gateways.
> 
> The question to the sipping group who are new to this question is: Where are
> there strong enough forces to encourage implementation of SIP in a way so that
> all good features that are within reach from consistent application of SIP are
> not spoiled by making shortcuts and imitating the limitations from the voice
> dominated PSTN?
> 
> 
> 
> Regards
> 
> Gunnar 
> 
> -------------------------------------------
> Gunnar Hellström
> Omnitor AB
> Renathvägen 2
> SE 121 37 Johanneshov
> SWEDEN
> +46 8 556 002 03
> Mob: +46 708 204 288
> www.omnitor.se
> [email-masked]
> --------------------------------------------
> 
>> 
>> -----Original Message-----
>> From: [email-masked]  [mailto:[email-masked]]On Behalf Of
>> Gregg  Vanderheiden
>> Sent: Monday, May 31, 2004 6:25 AM
>> To: 'Paul  E. Jones'; 'Arnoud van Wijk'; 'Gunnar Hellstrom'; 'Mundra,
>> Satish'; 'avt  IETF'; 'Toip list'
>> Subject: RE: text/T140 and audio/t140 was: [avt]  Comments/questions on
>> draft-ietf-avt-rfc2793bis-04
>> 
>> 
>> 
>> 
>> Hmmm
>> 
>> 
>> 
>> If we don't change  from audio to T140-IP at all the fringes of the IP
>> network  then we risk all  the problems inherent in TTY over IP and make it
>> very hard to move off of TTY  in the future since it will be embedded in.
>> 
>> 
>> 
>> Yes?
>> 
>> 
>> 
>> 
>> Gregg
>> 
>> --  ------------------------------
>> Gregg C  Vanderheiden Ph.D.
>> Professor  - Ind. Engr. & BioMed  Engr.
>> Director - Trace R & D Center
>> University of  Wisconsin-Madison
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From:  [email-masked] [mailto:[email-masked]] On Behalf
>> Of Paul E. Jones
>> Sent: Wednesday, May 26, 2004 3:23  PM
>> To: Arnoud van Wijk;  'Gunnar Hellstrom'; 'Mundra, Satish'; 'avt IETF'; 'Toip
>> list'
>> Subject: Re: text/T140 and audio/t140  was: [avt] Comments/questions on
>> draft-ietf-avt-rfc2793bis-04
>> 
>> 
>> 
>> 
>> 
>> Arnoud,
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> You are correct that not every  residential GW will be used to call to a PSTN
>> GW, but I will argue that most  calls will be to PSTN GWs for a period of
>> time.  After that period of  time, we will see a healthy mix of on-net and
>> off-net calls, ultimately ending  up with most calls being on-net.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> However, anytime that we connect a  PSTN textphone to a residential gateway,
>> there is a very high degree of  probability that the user will call another
>> user who is also using a PSTN  textphone, either connected to the PSTN or
>> hanging off of a residential  gateway.  So, the use of audio/t140 would still
>> be quite useful and would  probably be the likely mode for exchanging text.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I am not suggesting that the  residential GWs not support text/t140-- they
>> should for the benefit of  interconnecting to pocket PCs or personal
>> computers running software that  allows one to truly have simultaneous voice,
>> video, and/or text.   Likewise, we should see PSTN gateways support
>> text/t140, too.  I just  think that any device which interconnects with a
>> legacy TTY will likely  propose audio/t140 and I think that's OK.  If that
>> device calls a user on  a PC, then the mode of communication should be
>> switched to text/t140-- and SIP  offers that kind of negotiation.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Paul
>> 
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> 
>>> 
>>> 
>>> From: Arnoud van  Wijk <mailto:[email-masked]>
>>> 
>>> 
>>> 
>>> To: 'Gunnar Hellstrom' <mailto:[email-masked]>  ; 'Mundra,
>>> Satish' <mailto:[email-masked]>  ; 'Paul E. Jones'
>>> <mailto:[email-masked]>  ; 'avt IETF' <mailto:[email-masked]>  ; 'Toip
>>> list' <mailto:[email-masked]>
>>> 
>>> 
>>> 
>>> Sent:  Wednesday, May 26, 2004 3:57 PM
>>> 
>>> 
>>> 
>>> Subject: RE:  text/T140 and audio/t140 was: [avt] Comments/questions on
>>> draft-ietf-avt-rfc2793bis-04
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Gunnar..
>>> 
>>> Amen!
>>> 
>>> 
>>> 
>>> That is also my  feeling.
>>> 
>>> That is why I am  trying to limit the uses for audio/t140.
>>> 
>>> I still feel  unhappy about audio/t140.
>>> 
>>> And the answers  from others that a residental gateway will use audio/t140
>>> makes me  uneasy.
>>> 
>>> 
>>> 
>>> The argument that  such residental gateway will be used for mainly PSTN
>>> callsŠ.I do not agree.  It can also be through a VoIP server at your local
>>> network provider. And  those can be interconnected with other local ISPs and
>>> such. It is not  default to PSTN. (right now in Holland, VoIP services are
>>> starting, with a  residental gateway/modem and it is not aimed pstn only).
>>> 
>>> So lets keep the  freedom of the IP telephony and focus on text/t140 for
>>> residental gateways!
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Greetz
>>> 
>>> 
>>> 
>>> Arnoud
>>> 
>>> 
>>> 
>>> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 22 Jun 2004 22:46:03 +0200

Cullen and all,
Thanks for taking the discussion on real time text conversation into SIMPLE.

So far, I have regarded SIMPLE to be a messaging protocol, that handles a medium level of
timing requirements with complete messages in video, text, voice and images. And Server
based?
Right?
It definitely serves its purpose very well, and I really wish it will create some openness
in the messaging world.

What we have in avt and sipping in the text/t140 (rfc2793 and RFC2793bis ) is a real time
character-by-character text protocol, ready to flow in parallell to voice and video in a
regular Multimedia IP call. Based on RTP, but with good reliability.
It has been proven that it is needed as a companion to the voice and video paths of phone
calls.

Of course we want to see it more implemented to give full benefit to users who need or
want text in the calls. It is so easy to implement. It uses all the same mechanisms as the
other real time media in the call.

I see multimedia divided in at least three time relations.

1. Real time conversation. With video, text and voice flowing in real time straight
between two terminals.

2. Messaging. Compose a message and transmit. Usually via a server. SIMPLE, SMS.

3. Stored and editied multimedia for retrieval or broadcasting.

Cullen, you indicate that you think it would be easier to get to widespread implementation
by making SIMPLE handle character-by-character transmission, than by making the videophone
producers add the real time text RTP? Why, and would it not be a complicated mixed
protocol for a call, with straight SIP call establishment for the video and voice media,
and then involving SIMPLE and its server for the text part???????????

Is it not more straightforward to just add another RTP medium to the call? It is already
proven, implementations exist, the medium flows wherever the other media flows.

Regards

Gunnar

>From: Cullen Jennings [mailto:[email-masked]]
>Sent: Tuesday, June 22, 2004 4:44 AM
>To: Gunnar Hellstrom; 'Toip list'; 'Mundra, Satish'; 'Arnoud van Wijk';
>'Paul E. Jones'; Gregg Vanderheiden; [email-masked]
>Subject: Re: [Sipping] RE: text/T140 and audio/t140 was:
>[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jun 2004 19:25:58 -0400

> see if they can be addressed in IM.

Cullen,

I am inclined to agree with you up to a point. It would be good if your 
average IM client had this capability. But I don't think real time text 
itself is a reasonable substitute for IM. I used to think real time text 
was just a bad idea, but Gunnar now has me convinced that it has a role, 
especially for the hard of hearing, but also for certain real time 
situations like real time translation and captioning for video. For 
other purposes I find the stuttering of character-at-a-time text really 
annoying. (I usually don't want to watch while someone corrects their 
spelling and changes their mind about what they want to say.)

Since the text/t140 and audio/t140c is already defined, I see no reason 
to worry about those requirements in something like MSRP.

The more likely convergence to me is to work out the offer/answer usages 
so that support for these can coexist in a single device. I see no 
reason why my IM client can't support both. Hopefully I would normally 
find myself using message-at-a-time communication, but if I found myself 
talking to a RTT device the device and its UI should be able to 
accomodate that.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jun 2004 08:56:45 -0400

Gunnar Hellstrom wrote:
> producers add the real time text RTP? Why,

Seems to me the question is what devices (hard or soft) have a suitable 
UI for dealing with text?
- A simple audio phone doesn't.
- A "hard" video phone with just a number pad for input isn't well
   suited for text input. It could potentially do text output, but that
   may not fit well - especially not if a full history is to be kept.
- A soft video phone, on a computer with a keyboard, has less of the
   limitations of a hard video phone. But the closer it attempts to
   emulate a hard video phone, or an audio phone, the less suited it
   will be.
- OTOH, an IM client has all the mechanics for text entry and display,
   including the full conversation log. So it has most of the UI needed
   to support real time text.

I don't have experience with a real time text application, but I suspect 
that it may prefer a UI somewhat different than an IM client UI, so 
perhaps there is a market for a custom UI for those that use this medium 
a lot. But I also suspect that the IM client UI can be easily adapted so 
that it is reasonably suitable for real time text - good for those who 
use it occasionally.

 > and would it not be a complicated mixed

This should be no more difficult than dealing with an audio/video call - 
that involves establishing separate audio and video media streams. Its 
just a matter of establishing the third stream (or the 2nd stream if 
text is used *instead* of voice.)

It has certainly been my goal all along in the MSRP work to ensure that 
IM is indeed just another media stream.

> proven, implementations exist, the medium flows wherever the other media flows.

Its just another medium in any case. Perhaps text over RTP is marginally 
simpler just because establishing RTP based media streams is more 
familiar than TCP based ones. But TCP has been chosen for MSRP because 
it is better suited to the message oriented protocol that doesn't have 
tight real time constraints.

The only real new complexity here (and it isn't *that* new) is working 
out how to handle offer/answer among endpoints that can do both MSRP and 
text/t140 but consider them mutually exclusive.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 23 Jun 2004 15:38:58 -0500

> timing requirements with complete messages in video, text, voice and images. And Server

Nope.

SIMPLE is just a working group. There is no SIMPLE protcol. The working 
group is dealing with presence and messaging using SIP, defining 
messaging transport protocols like MSRP, and defining presence data 
manipulation protocols like XCAP.

MSRP, as defined, is much as you have described above. SIP MESSAGE 
requests can also be used to do less conversational messaging.

Would your requirements be meetable with a real-time mode for MSRP? 
Something to think about.

. . .

> and then involving SIMPLE and its server for the text part???????????

MSRP is already negotiated using SIP. MSRP can be set up in conjunction 
with RTP by a SIP negotiation. MSRP can be made to work with or without 
relays. MSRP is reliable. MSRP can be securely negotiated through an 
MSRP-aware firewall. But right now, it buffers at the message level 
rather than the character level and doesn't deal with intercharacter 
timing, so all it misses is your rough-approximation-of-real-time 
requirement.

> proven, implementations exist, the medium flows wherever the other media flows.

Sure, it's straightforward. But I still feel that RTP is just not 
suitable for text, no matter HOW much forward error correction you 
apply. It doesn't detect and react to congestion. It gets delivered 
out-of-order. It gets discarded by busy routers, and not resent. You 
might do a lightweight UDP protocol with in-order delivery and 
incremental acknowledgement, but that wouldn't be RTP. It would be more 
like ntalk, which has been around for a while.

--
Dean

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 23 Jun 2004 23:11:11 +0200

Dean,
Thanks for explanations.

You say:
"Sure, it's straightforward. But I still feel that RTP is just not
suitable for text, no matter HOW much forward error correction you
apply. It doesn't detect and react to congestion. It gets delivered
out-of-order. It gets discarded by busy routers, and not resent. You
might do a lightweight UDP protocol with in-order delivery and
incremental acknowledgement, but that wouldn't be RTP. It would be more
like ntalk, which has been around for a while."

Our experience with a couple of generations of RFC2198 redundancy is very good. Remember,
if you have 10% loss, already by one repetition you are down to 0.1*0.1 = 1% loss. If you
repeat once more, you get 0.01*0.1 = 0.1 % loss. That is far better than any typist
already with only two generations. Takes very little space.

I just started up an installation where we happened to get 40% loss because of some
network configuration problems. Video was lousy, audio sounded pling scratch, but text got
through beautifully without problems.

Bringing packets back to order in case of misordering is a simple procedure normal for
RTP.

One good thing is that the medium gets through where the other media gets through. No
extra protocol compatibility needed in the routers, just plain SIP RTP compatibility.

Also the multiparty meeting arrangements gets so familiar because they are similar to
video.

SIMPLE has no ambitions to carry real time audio and video. So, why real time text when
there is already one acknowledged way to transmit text that has been standard since 2000,
and is entered in a number of higher level documents?

Gunnar

Gunnar Hellstrom
Renathvagen 2

>From: Dean Willis [mailto:[email-masked]]
>Sent: Wednesday, June 23, 2004 10:39 PM
>To: Gunnar Hellstrom
>Cc: Cullen Jennings; 'Toip list'; [email-masked]
>Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Jun 2004 18:13:36 -0500

A long time we had a meeting and you said you were interested in a solution
that helped people that could not use voice in one or both directions. I
said that sounded good and pointed out that the problem was a business case
problem not a technical problem.

Various people made good arguments that that you need to send it character
by character not line by line. You convinced people - thank you. I imagine
that people than can use voice will find this useful to for example the same
reasons you do. It's good you got this point across. I did not understand
this when I first starting talking to people. I get it now.

Now, I want to ask yourselves seriously - what is your goal here now. Do you
want to get a solution to this that is widely deployed or is their a
particular technology you want to push? Do you want the problem solved no
matter what the solution or did you just invent the problem to push a
particular solution in the first place?

MSRP is a protocol that might be able to be a solution. The odds are
reasonable that it will be widely deployed. If this happens, the marginal
effort to make it meet your requirements would be extremely low and probably
you don't need a business case to make it happen. It will get implemented
for the fun of it at the same time because it will not take any extra
effort.

As you point out with T140, it has been standardized for years yet, has it
really been very widely implemented? Will it be implemented given the
business case that has been presented for it so far. I don't know, maybe,
these things take time and effort to catch on, but I find it somewhat
doubtful. I would find if very sad to see a group of people who really want
to have a solution for this problem to get politically maneuvered into a
place where the vendors can say their equipment is fine for section 508 or
whatever supercedes it. Yet when the whole systems deploys, for some reason
only voice will work but it will not be the fault of any equipment vendor.
Be wary of solutions where the phones and GWs will send Voice Band Data
packets from which someone else need to extract the data . It will be hard
to find the someone else.

If you want a solution to the problem, here is my advice: Tell the SIMPLE WG
that you have a requirement for character by character text. I have not seen
any requirements other than this that MSRP does not already meet. If you
want this, now is the time to make sure SIMPLE agrees to do it. This does
not stop you from pursuing the ever loved t140 solutions - you can pursue
those too. If you want MSRP to be more than what you refer to as IM, now
would be a good time to make sure MSRP is right.

I'm sure some people will argue that the t140 solutions are less work than
MSRP. That may or may not be true but it is irrelevant. I think we need to
think about which one is most likely to get implemented. You say IM is not
appropriate in all situations, and you want char-by-char on every phone.
That sounds good, but think bigger, how about char-by-char on every phone
and on every future IM device. There's going to be a lot more of these than
phones and every device that has a keyboard is probably going to be an IM
device. Go big - make IM work for what you need on everything with a
keyboard and on all the phones. A solution that works for both is more
likely to happen than one that just works for phones.

Cullen

PS - I agree with  Paul K and Deans comments

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 25 Jun 2004 08:29:23 +0200

Cullen,

Important factors for real time conversational text are:

1. Wide deployment
2. Good opportunities to combine with voice and video in real time calls
3. Same network traversal opportunities as voice and video. No worse or different NAT and
firewall problems than for the other real time media.
4. Meet all the other functional requirements you started with citing.
5. Be careful with tendencies for fragmentation in options and various solutions for the
same network type, because that may lead to less interoperability.
6. A scalable solution that survives even to the stage when it is deployed and used in
every phone.

So, checking MSRP in positive mood, I find:

no 2 is likely OK.
no 3 is likely not solved today, but if you achieve wide deployment it may become solved.
no 4 is probably OK, I am not sure about influence on congestion and network load. MSRP
packets seem to get quite long, and we need to transmit every 300 ms to get satisfied
users.
no 6 is no blocking factor. MSRP can apparently be used peer-to-peer.
no 1 is hard to know. Usually it is not the choice of protocol that leads to market
success. You indicate that if we made sure that there is a conversational mode for MSRP,
we would benefit from a possible success of SIMPLE. I realize the opportunity.

no 5 is the most tricky one. If you do text/t140 and I do MSRP/RTT we get no
communication. That is the situation we came from, with the fragmented world of seven
incompatible protocols for text telephony in PSTN. Now time has come for harmonisation and
interoperability in the world of text communication.
text/t140 is standardised since year 2000, and included in many documents as the way to
go. All what we need is already approved. We are just working with refinements and
deployment. So for now the deployment should not be confused by knowing that alternatives
may be coming that are in draft stage. If the alternative then comes with proper
mechanisms for negotiation in an offer/answer model it may be OK, if it adds very evident
value in terms of functionality or deployment opportunities. I see great risks with
fragmentation. That is the main threat to proper services.

What needs to be done in MSRP?
------------------------------
With that said, we could go into looking at MSRP to see what needs to be done.

I found most current specification suitable.

We have to define a MIME media type. It could be T.140 text without the RTP packetisation.
That is UTF-8 coded Unicode with some usage habit rules. It would be the payload from
RFC2793.

It should be buffered and sent every 300 ms or so.

In section 6.5.3 we have this text:
--------------------------------------------------------------
When an endpoint receives a SEND request, it MUST perform the
   following steps.

   1.  Check that it has state for a session with a local URL matching
       the To-Path value.  If no matching session exists, return a 481
       response.

   2.  Determine that it understands the media type in the body, if any
       exists.

   3.  If it does, return a 200 response and render the message to the
       user.  The method of rendering is a matter of local policy.
---------------------------------------------------------------------
It is only this sentence: "The method of rendering is a matter of local policy." that need
an addition for the real time case.
"The local policy for real time text shall be to display the text from each participant in
a separate contigous text display area. Time alignment with text transmitted according to
the examples in ITU-T T.140 is RECOMMENDED.

Can someone check what bandwidth usage we will cause when using MSRP if we have a rapid
typer, typing 9 character per second in English ( causing one byte UTF-8 per character),
thus shipping three characters per SEND request?

Over the years, T.140 for real time interactive text conversation has been specified to go
over:
- V.18 modem
- T.134 in  T.120 data conferencing
- H.224 for H.320 ISDN mulitmedia
- AL1   for H.324 multimedia opened through H.245
- RFC2793 for H.323 multimedia
- TCP     for H.323 multimedia
- RFC2793 for H.248 gateways
- RFC2793 for SIP
- RFC2793bis audio/t140c for V.152 gateways

So, I am positive to check if it reasonable to add MSRP to the list of transports,
provided we do not confuse current deployment activites and we do it in a way that
negotiate well with the current SIP RTP solution.

Gunnar

>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Cullen Jennings
>Sent: Friday, June 25, 2004 1:14 AM
>To: Paul H Kyzivat; Gunnar Hellstrom
>Cc: 'Paul E. Jones'; 'Arnoud van Wijk'; [email-masked]; Gregg
>Vanderheiden; 'Toip list'; 'Mundra, Satish'
>Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140
>was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
>
>
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 25 Jun 2004 10:33:22 -0500

Gunnar listed out a good set of requirements in RE: [Sipping] RE: 
text/T140 and audio/t140 was:[avt]Comments/questions on 
draft-ietf-avt-rfc2793bis-04

I'd like to add one requirement that every Internet protocol should 
meet, but many (especially early protocols) do not.

I'll phrase this as one absolutely critical requirement, and a couple of 
examples of what this means. I'll admit that the examples have a lot of 
overlap with each other. Perhaps someone has said this better -- if so, 
somebody please send me a reference . . .

Big Requirement: A user of the Internet must not interfere unfairly with 
other users of the Internet.

What does this mean in design terms?

1) A protocol or suite of protocols supporting an application MUST be 
both sensitive and reactive to network behavior in real time.

2) A protocol or suite of protocols supporting an application MUST not 
"flood" network links, stifle or starve other applications, or 
aggressively try to compensate for network limitations by using more 
bandwidth.

3) A protocol or suite of protocols supporting an application MUST react 
to network performance issues in a "fail-safe" manner. If there are 
problems with the network, this means either "backing off" until the 
situation gets better, or reporting the conditions up the 
decision-making tree to an agent with the power to terminate or suspend 
the application operation until things get better (or possibly, that can 
make things better by taking actions outside the scope of the 
application protocol).

4) A protocol or suite of protocols SHOULD be designed in such a way 
that implementations of applications using that protocol or suite of 
protocols meet the above requirements "by default", that is, without 
special effort on the part of the application builder.

5) The best protocols "play nice" by recording network behavior in real 
time and taking corrective action. This includes things like:

a) measuring end-to-end latency, drop rates, jitter, etc. and reducing 
transmission rates under degraded network conditions, perhaps by 
changing timing, encoding, buffering, packet size, or flo-control 
mechanisms.

b) Interacting with network nodes to gain additional data about network 
behavior and using this data to adapt behavior as in A. An example here 
might be TCP explicit congestion notification (ECN) or frame-relay 
foward and backward explicit congestion notification (FECN and BECN).

What does all this mean to us?

Let's thnk about this in the terms of real-time-text and RTP. I'll admit 
that RTT/RTP can be made to work, even under bad network conditions, but 
is it a "good citizen" of the internet?

Sure, RTCP gives us limited notification capability, and if used 
carefully in an application could meet most of the fundamental 
requirement. Problem is, nobody ever does it this way. When was the last 
time your GTT app popped up and said "I'm observing high loss on this 
link. Please type slower or give up." This is a failure of #4, above. 
Developers have to go out of their way to integrate RTCP status with the 
application and make the application adapt. Many implementors of RTP 
never get around to doing the RTCP part, and applications quite commonly 
ignore RTCP even if the stack they're written on supports it.

#1 requires that our system sense and react to real network conditions. 
RTT/RTP as you have outlined it doesn't. Instead, RTT just assumes the 
network is lossy and congested, and sends things redundantly, obeying 
its own timers rather than reacting to the ebb and flow of the network 
beneath it. As a consequence, RTT/RTP violates #2 and #3 as it "out 
competes" other users by just blasting out redundant transmissions 
whether they're needed or not.

I believe that, if we were designing the protocol today, RTP as it 
currently exists would not survive the review process. By requiring 
applications to deal with these complex transport issues, it makes the 
probability of "well-mannered" implementations quite low. We probably 
wouldn't use RTP for voice if we had something better-behaved, and we 
shouldn't use RTP for text when we have the option of using something 
that's better behaved.

Sure, RTP can be made to run with DCCP, and it probably will be some 
day. But unfortunately, that's probably a few years out before we see 
any kind of "critical mass", and there'll be a whole new can of 
firewall/NAT worms to untangle before we can really count on it working 
in the field.

So, what can we do now?

Options include:

1) Ignore these problems, because somebody else (perhaps the Bush 
administration) can be counted on to clean them up for us.

2) If we really need a synchronous real-time end-to-end network, forget 
about IP and use ATM for real-time text applications.

3) Require RSVP and per-RTT/RTP flow reservations.

4) See how close we can get to meeting our real-time needs with a 
network-friendly protocol like MSRP.

Personally, I prefer option 4, which begs the questions:

What exactly do we want for real-time text, what part of it cannot be 
implemented on a network that is not always a real-time network, and can 
we get close enough to get something useful out of an MSRP-like 
protocol? And is the SIMPLE working group willing to tackle this mission?

Here's a use case:

I'm going to chat with Arnoud. I send him a MESSAGE asking if he wants 
to talk. Arnoud responds by INVITE-ing me to an MSRP session. We 
exchange a few slow-text messages. As the conversation warms up, we 
decide switch to real-time text by clicking the "send in real time" 
buttons on our texters (which I presume just changes the buffering 
behavior in MSRP). When we're done, we send BYEs. Throughout the whole 
conversation, the TCP stacks in our devices were making sure we "played 
nice" with the other network users. Every now and then, the timing was a 
bit off, but it was pretty close, and we didn't break anybody's network 
or interfere unfairly with other applications. That's a good way to use 
the Internet.

--
Dean

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 25 Jun 2004 20:46:42 +0200

Dean,

You seem to claim that MSRP for real time text would behave better in congestion than RTP
with text/t140.

I do not think this can be a decision factor for selecting one of these protocols before
the other.

RTP for text is not at all causing the continous load as voice and video. Transmission is
done just when there is text to transmit, and then we have a default transmission rate of
3 packets per second.

In the last edition of rfc2793bis we added a lot of precautions for congestion.
But we also added that in case of severe congestion, other streams could be cut out, and
the conversation only continue in text in order for the whole conversational application
to behave well in the network.

Here is the last edition -06: ( - 07 should be out any day now )
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-06.txt

I do not see enough concerns about possibility to combine the text session with
simultaneous voice in the discussion. The thoughts about MSRP seems to be too far from the
real time media that I would not yet dare to rely on it as a base for real time text
during calls.

I think we would be better off, having a reference in MSRP saying that when there are real
time requirements, a text/t140 RTP stream SHALL be opened and the text conversation
performed there instead.

Then we can win-win in getting the mass deployment you expect for IM and the real time
behaviour that is needed in a more intensive text discussion.

Planning for emergency service text handling, for gatewaying to text in other networks etc
could continue as now and we would have a smooth transition and big market for future text
based services in all time aspects.
------

Did you see my question about what bandwidth an MSRP text session with three payload bytes
per packet every 300 ms would generate. That figure is important for judging if the
proposal to use MSRP is at all realistic. You who know MSRP can probably tell this easily.

------

Gunnar

>Sent: Friday, June 25, 2004 5:33 PM
>To: Gunnar Hellstrom
>Cc: 'Toip list'; [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Jun 2004 07:26:18 -0700

Thank you that is exactly the type of email I was hoping for - we can figure
out it is a possibility or not.

As a very rough cut on some bandwidth estimates for the 1 message every 300
ms with 3 characters. An example message from the MSRP draft with 3
characters was about 194 bytes resulting in approximately 6 Kbps rate. Seems
like this will probably be less than voice but is still concerning. The
wireless people clearly want to keep the size of this message down too so it
will be interesting to see how the protocols comes out.

I suspect the NAT issues are not that big a deal. For the audio call to work
at all, both signaling and RTP needed to work and where that is possible it
is probably possible to make any of the solutions work from a NAT traversal
point of view. Ditto for any logging/RAVEN/CALEA type things.

The scale issues are less concerning for me. Odds are that a small
percentage of the overall IM or voice traffic would be involved in this type
of messaging make the total impact minimal on things other than the
endpoints and GWs. 

A silly question about the mime type. Could text/plain work?

I get your point that having both t140 and MSRP may be worse than just t140
but not sure if I agree or not - it's a very hard one to know. I imagine
that in the end, figuring out this one largely determines what we should do
here.

Cullen

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 26 Jun 2004 18:41:47 +0200

Culllen,

You ask:
"A silly question about the mime type. Could text/plain work?"

No,
All these various 7 and 8 bit character sets have caused enough confusion in the world and
should be abandonned. Only Unicode is usable without confusion.
To open for a subparameter of text/plain specifying a character set, and having US-ASCII
as the default is not suitable in modern communication. I hope you do not intend to use
this coding in other parts of simple!

There are eternal mistakes when these character sets are missing, or applications try to
translate between them. The national characters get destroyed or even whole character sets
get non displayable.

More specifically, you have to set limits to what editing you can allow during a real time
conversational session.

And you may want to add some specified rendering effects.

That is what you get by specifying ITU-T T.140 instead of just saying UNICODE.

There has been some mentioning about T.140 as a transmission mechanism, but that is not
what it is. It is a simple set of rules around How to use Unicode in a real time
conversation.

We should look at this with open minds, but it is likely that we end up with something
approximately like T.140 for the text coding. Let us see.

Editing:
In a real time conversation you need to allow some "remote editing". The only reliable way
is to allow erasure of the last character for correction. A number of characters back must
be guarnateed to be stored in a buffer so that erasing into it can be done.
Insertion of new line is also needed.
Allowing other forms of cursor positioning with effects on the remote side is risky
because the layout must be allowed to be completely different. Therefore other cursor
controls are not included in T.140.

Rendering:
There might be some interest in adding colour to the text or other rendering effects. This
is allowed in T.140, by using such codes from ISO 6429, but I do not know any
implementations supportning them. When you are in a real time text conversation, you tend
to concentrate on the typing text and ignore such effects.
It is important to remember that there are many varied writing directions in the world, so
that it must be possible to display text with writing direction right to left etc.

Using T.140 would make it easy to arrange gateways to other forms of text conversation. I
have not heard anyone lacking any functions in T.140.

Negotiating the real time mode:
There must be a way to tell both sides that we now enter a real time text session. That
should then cause transmission characteristics go real time, and reception and display to
change to adding incoming text to a contigous field for incoming text and be prepared to
do the edits.
I did not see any extra field for indication of modes duing the session, so a new mime
subtype could be used as the way to signal to the applications to enter the real time
mode.
Already in the SIP session setup it must be possible to see that the session is offered in
order to handle real time text, so that both sides can select a common method. So, the
current offering in MSRP with just m=message is not sufficient.

It must also be planned to be possible to specify preferences and callee capablilities for
text.

Gunnar

>Sent: Saturday, June 26, 2004 4:26 PM
>To: Gunnar Hellstrom
>Cc: 'Paul E. Jones'; 'Toip list'; [email-masked]
>Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and
>audio/t140was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Jun 2004 12:44:07 -0700

> change to adding incoming text to a contigous field for incoming text and be

Indeed - I was thinking that the senders application could allow them to
select their preference for what they were sending and indicate in the
arriving data that it was character by character mode so the receive could
display and edit appropriately. Somewhat interesting questions about getting
out of this mode. 

I was sort of wondering what the 2973bis draft was going to say about
getting and INT sequence in the T.140 packets. It seemed strangely silent on
this.

It might be somewhat difficult to deal with given it is mixing signaling
into a media stream. I'm particularly interested to see the security
considerations for this.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Jun 2004 12:43:55 -0700

> this coding in other parts of simple!

My assumption is that the charset would be utf-8 - I understand that
us-ascii is the default for text/plain but it seems unlikely that we would
not mandate utf-8.

> And you may want to add some specified rendering effects.

Hmm, I suspect that is true that IM will want that - including HTML, RTF,
and Emoticon stuff. The richness of existing IM clients with respect to this
is one of the advantages of it.

I have to admit my recollection of T.140 is a bit vague - What rendering
effects does it support? I seem to recall some Select graphic Renditions
stuff that did not seem of much use but I forget.

What does T.140 support that is needed.

> Insertion of new line is also needed.

Agreed - so basically you need to send Back Space and Newline?

> controls are not included in T.140.

Make sense

> to concentrate on the typing text and ignore such effects.

Yes 

> that it must be possible to display text with writing direction right to left

Of course

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 26 Jun 2004 22:51:42 +0200

Cullen,

You say:
"I was thinking that the senders application could allow them to
select their preference for what they were sending and indicate in the
arriving data that it was character by character mode so the receive could
display and edit appropriately."

Yes, and the way to indicate that could be by MIME type and subtype. Do you have any other
proposal?

Maybe you could instead introduce a new indicator in the "continue-flag" field to mean
"display and treat this in real time mode". ?  Such information seems related to the
current variants of coding in that field.

Ending real time mode would be indicated by sending the regular mime type, or using the
current "continue-flag" codes.

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

About colours, rendering effects and emoticons:
T.140 can make use of the ones available in ISO 6429. It contains the common set of
foreground colours, background colours, flashing, bold underlining etc. ISO 6429 is also
mentioned in Unicode to be the normal set for rendering effects.

I do not know if emoticons would be popular in real time mode if they were readily
available from the user interface.
Some emoticon-like characters are available in Unicode, but if a comprehensive set is
needed, it would need to be introduced from other sources. If wanted.

>Sent: Saturday, June 26, 2004 9:44 PM
>To: Gunnar Hellstrom
>Cc: STF267; 'Paul E. Jones'; 'Toip list'; [email-masked]
>Subject: Re: [Simple] RE: Betr.: Using MSRP for real time text
>conversation
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jun 2004 10:06:28 -0400

> current "continue-flag" codes.

I think the continue-flag would result in problems. For instance, relays 
might decide to buffer and merge message fragments, screwing up the 
realtime delivery.

It seems to me that this is truly an application level semantic on how 
to render multiple incoming messages, so a content-type seems quite 
appropriate. Perhaps it would be sufficient to use text/t140 as the 
content type.

I'm still dubious that sending this over MSRP is the right way to do, 
but it is at least worth discussing.

	Paul

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Mon, 28 Jun 2004 18:29:11 +0200

I agree, this is an open feasability discussion.

OK, of used, the MIME type would be the indicator that the usage is real time.
Yes, it would be convenient if we could use text/t140. I am afraid though that the MIME
registration happens to be linked to its RTP packetisation.

Its use would influence both transmitter?s behaviour that need to transmit with a real
time flow, and receiver?s behaviour who need to add incoming text to the incoming window.

Seems uncomplicated.

Gunnar

>Of Paul Kyzivat
>Sent: Monday, June 28, 2004 4:06 PM
>To: Gunnar Hellstrom
>Cc: Cullen Jennings; STF267; 'Toip list'; [email-masked]; 'Paul E.
>Jones'

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Mon, 28 Jun 2004 18:39:30 +0200

It is just User Agent behaviour and interface.
Aka a switch on the IM client for a "real-time chat mode" with the current
IM customer you communicate with. And perhaps only show that chat option if
the other UA does support Interactive text.

Nice to mention. 

Cheers

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gunnar Hellstrom
Sent: maandag 28 juni 2004 18:29
To: Paul Kyzivat
Cc: Cullen Jennings; STF267; 'Toip list'; [email-masked]; 'Paul E. Jones'
Subject: RE: [Simple] RE: Betr.: Using MSRP for real time text conversation

OK, of used, the MIME type would be the indicator that the usage is real
time.
Yes, it would be convenient if we could use text/t140. I am afraid though
that the MIME
registration happens to be linked to its RTP packetisation.

Its use would influence both transmitter?s behaviour that need to transmit
with a real
time flow, and receiver?s behaviour who need to add incoming text to the
incoming window.

Seems uncomplicated.

Gunnar

>> Yes, and the way to indicate that could be by MIME type and subtype. Do
you
>have any other

-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/toip_archive/maillist.html

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jun 2004 12:49:17 -0400

> the other UA does support Interactive text.

An advantage of this approach is how easy it is to negotiate, and to 
fall back to simpler behavior. The mechanism for listing supported 
content types is already present. Fallback is to (message oriented) 
text/plain.

	Paul

>>>arriving data that it was character by character mode so the receive
>>
> could
> 
>>>Maybe you could instead introduce a new indicator in the "continue-flag"
>>
> field to mean
> 
>>>"display and treat this in real time mode". ?  Such information seems
>>
> related to the
> 
>>>Ending real time mode would be indicated by sending the regular mime
>>
> type, or using the
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Jun 2004 14:01:32 -0500

> other users of the Internet.

Joel Halpern correctly pointed out to me that RFC2914/BCP41 is the 
definitive reference for this topic. Everybody who hasn't read it this 
week should go read it again. Joel also mentioned that the IESG seems to 
be serious about making sure that new work addresses the concerns raised 
in RFC2914. An example is the Forwarding and Control Element Seperation 
(FORCES) work, which now includes in its charter:

o Specification of IP-based protocol for transport of the
   controlled objects. When the control and forwarding devices
   are separated beyond a single hop, ForCES will make use of an
   existing  RFC2914 compliant L4 protocol with adequate reliability,
   security and congestion control (e.g. TCP, SCTP) for transport
   purposes.

and as a consequence has effectively rejected use of UDP as a general 
transport for routing control traffic.

--
dean