RE: [Simple]Re:I-DAction:draft-hellstrom-simple-text-transmission-00.txt

[Gunnar Hellström <[e-mail]>]

Paul,
Here is another clue, that also is not sufficient:

Tere is a new draft proposing registration of the media feature tag
sip.real-time-text:

Title : Registration of the Real-time-text Media Feature Tag 
http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-01.txt

A SIP UA having the capability to support real-time-text through any
transport should indicate that by real-time-text=full in the contact header.

Then the UA:s can negotiate use of e.g. MSRP for real-time-text by checking
the proposed a=real-time-text parameter of the sdp for MSRP. 

That would make both UAs to include only real-time capable relays in the
chunk addressing.
But how would they know what relay to use except through users configuring
their service environment by hand?

Is there any feature support declaration on relays available for inspection
when you search for relays?

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


When discussing this topic, it might be good to know that there is a set of
drafts covering different aspects of the real-time-text concept. 

1. Title : Registration of the Real-time-text Media Feature Tag 
http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-01.txt
2. Title : Presentation of Text Conversation in realtime and en-bloc form
http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-04.txt
3. Title : Text media handling in RTP based real-time and message
conferences
http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-00.txt
4. Title : Real-time text interworking between PSTN and IP networks
http://www.ietf.org/internet-drafts/draft-hellstrom-txtgwy-00.txt
5. Title : Framework for real-time text over IP using the Session Initiation
Protocol (SIP)
http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-08.txt

Gunnar 


-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
Tel: [phone]
www.omnitor.se

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: Monday, January 14, 2008 11:32 PM
To: Geir Arne Sandbakken
Cc: Gunnar Hellström; Simple WG
Subject: Re:
[Simple]Re:I-DAction:draft-hellstrom-simple-text-transmission-00.txt

The C-D provides a possible way to detect that special handling is required
on this message. But it doesn't provide any assurance that relays will
provide that processing. Something else is still required to deal with that.

	Paul

Geir Arne Sandbakken wrote:
> My fault. The header is fine by me. I just got stuck on the examples which
do not include the header.  
> 
> Geir Arne
> 
>> -----Original Message-----
>> From: Gunnar Hellström [mailto:[e-mail]]
>>
>> Geir Arne,
>>
>> You say: "you might be required to tag each MSRP message"
>>
>> In section 5, item b we have this proposal:
>>
>>    b.  A Content-disposition=immediate-presentation to be included in
>>    the MSRP headers in the chunks and messages.  
>>
>> (This new value of Content-disposition then needs to be registered by 
>> IANA.
>> )
>> Do you regard tat to be a suitable tagging, or do you have any other 
>> mechanism in mind that is possible to use on text/plain, 
>> Charset=utf-8
>>
>> Gunnar
>> -------------------------------------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [e-mail]
>> Tel: [phone]
>> www.omnitor.se
>>
>> -----Original Message-----
>> From: Geir Arne Sandbakken [mailto:[e-mail]]
>> Sent: Monday, January 14, 2008 7:32 PM
>> To: Gunnar Hellström; Paul Kyzivat; Simple WG
>> Subject: RE:
>> [Simple]Re:I-DAction:draft-hellstrom-simple-text-transmission-00.txt
>>
>> Gunnar,
>>
>> If packet rate, bandwidth or processing limitations are a concern,  
>> you could think about adding a throttle mechanism.
>> Like an MSRP method that would request the client to adjust it's 
>> sample rate, or even turn off/on a real time text extension.
>>
>> As an MSRP session can be used for many purposes, you might be 
>> required to tag each MSRP message.  The relay could then treat the 
>> messages differently on a message by message basis.
>>
>> Cheers,
>> Geir Arne
>>
>>> -----Original Message-----
>>>
>>> Paul,
>>> The real-time feature transmitting characters in
>> time-sampled chunks
>>> as they are avialable really gives new life to text-IM. Many of the 
>>> annoying drawbacks of traditional sentence-wise IM are resolved by 
>>> this feature. You do not need any presence indicator that the other 
>>> person is typing, when you really whant to know is WHAT is
>> typed. Here
>>> you get it. And you do not need to rush composing your message to 
>>> completion so that the other participant shall understand a new 
>>> appearing situation. Your first keystrokes will be
>> immediately visible
>>> and make it apparent that you are about to explain the situation.
>>> There are numerous situations when the real-time text
>> feature is very
>>> useful.
>>>
>>> But you are right in pointing at issue 4, saying that MSRP
>> relays may
>>> need to know that they should avoid buffering an re-combination of 
>>> chunks when the chunks are used for real-time text. Some additional 
>>> rules may be needed for relays. E.g. "do not recombine chunks with 
>>> text/plain contents and less than 10 characters of payload".
>>>
>>> Also multi-party sessions, with more than one active user
>> typing may
>>> cause an extensive message flow. I have calculated that one message 
>>> flow with three transmissions per second, including relay
>> addressing,
>>> takes approximately 17 kbit/s and
>>> 12 packets / second. With three typers it becomes 51 kbit/s and 36 
>>> packets/s for this session between the relay and the user terminal.
>>>
>>> So, an issue 5 might be needed: Is it feasible, regarding bandwidth 
>>> consumption and processing? If not, can something be done
>> to make this
>>> important functional enhancement of text-IM feasible?
>>>
>>> There is now also a draft available talking more about the 
>>> presentation aspects that gives complementing information:
>>>
>> http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-04.tx
>> t
>>>
>>>
>>> Thanks
>>> Gunnar
>>> -------------------------------------------------------------------
>>> Gunnar Hellström
>>> Omnitor
>>> [e-mail]
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: Sunday, January 13, 2008 4:53 AM
>>> To: Simple WG
>>> Subject: [Simple] Re:
>>> I-DAction:draft-hellstrom-simple-text-transmission-00.txt
>>>
>>> I find this to be pretty interesting. My feeling has been that the 
>>> best chance for pervasive support of real time text is for it to be 
>>> incorporated into a widely used application and protocol.
>> IM qualifies
>>> as a widely used application, though MSRP doesn't yet qualify as a 
>>> widely used protocol.
>>> This could however be synergistic - it might result in some
>> pressure
>>> to support MSRP.
>>>
>>> BUT the problem mentioned as Issue 4 is potentially fatal. 
>> If relays
>>> are involved in the session, it is likely that they would think it 
>>> appropriate to buffer and re-chunk the chunks, destroying the real 
>>> time characteristics. I don't see how to avoid this unless
>> some way to
>>> negotiate the behavior of relays can be devised.
>>>
>>> Also, if relays multiplex multiple MSRP sessions on a
>> single, that can
>>> also impact the real time characteristics.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> [e-mail] wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>> 	Title           : Coding and transmission of text in 
>>> real-time and
>>> en-bloc mode based on MSRP
>>>> 	Author(s)       : G. Hellstrom, et al.
>>>> 	Filename        : 
>>> draft-hellstrom-simple-text-transmission-00.txt
>>>> 	Pages           : 15
>>>> 	Date            : 2008-01-09
>>>>
>>>> This memo describes conventions for exchange and
>>> presentation of text
>>>> in SIP sessions through the Message Session Relay Protocol
>>> MSRP.  It
>>>> covers two different methods for taking the initiative to
>> transmit.
>>>> These methods are timer initiated real-time text and user
>> requested
>>>> en-bloc transmission in Messaging.  The document gives specific 
>>>> guidance on handling of text presentation and presentation
>>> control of
>>>> conversational sessions.  It specifies how the capability
>>> to conduct
>>>> MSRP sessions with real-time text is declared so that session 
>>>> negotiation can make decisions on what transport protocol
>>> to use and
>>>> how to route the calls to get the desired support for text 
>>>> communication.
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
>>> http://www.ietf.org/internet-drafts/draft-hellstrom-simple-tex
>> t-transmission
>>> -00.txt
>>>> To remove yourself from the I-D Announcement list, send a
>>> message to
>>>> [e-mail] with the word unsubscribe in
>>> the body of
>>>> the message.
>>>> You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>> to change your subscription settings.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP. 
>> Login with the
>>>> username "anonymous" and a password of your e-mail address. After 
>>>> logging in, type "cd internet-drafts" and then
>>>> 	"get draft-hellstrom-simple-text-transmission-00.txt".
>>>>
>>>> A list of Internet-Drafts directories can be found in 
>>>> http://www.ietf.org/shadow.html or 
>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>> Internet-Drafts can also be obtained by e-mail.
>>>>
>>>> Send a message to:
>>>> 	[e-mail].
>>>> In the body type:
>>>> 	"FILE
>>> /internet-drafts/draft-hellstrom-simple-text-transmission-00.txt".
>>>> NOTE:   The mail server at ietf.org can return the document in
>>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>>> 	command.  To decode the response(s), you will need "munpack" or
>>>> 	a MIME-compliant mail reader.  Different MIME-compliant
>>> mail readers
>>>> 	exhibit different behavior, especially when dealing with
>>>> 	"multipart" MIME messages (i.e. documents which have been split
>>>> 	up into multiple messages), so check your local documentation on
>>>> 	how to manipulate these messages.
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader 
>>>> implementation to automatically retrieve the ASCII version of the 
>>>> Internet-Draft.
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> -
>>>> --
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
>>> __________ NOD32 2785 (20080111) Information __________
>>>
>>> Detta meddelande är genomsökt av NOD32 Antivirus.
>>> http://www.nod32.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/simple
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/simple
>>
>> __________ NOD32 2789 (20080114) Information __________
>>
>> Detta meddelande är genomsökt av NOD32 Antivirus.
>> http://www.nod32.com
>>
>>
>>
> 

__________ NOD32 2789 (20080114) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com




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