[Iptel] RE: [Sipping] New draft on end system communication services

Xiaotao,

The main text medium I think about is the real time conversational text medium defined in
rfc2793 and rfc2793bis.
It is declared as any other real time medium in sdp with m=text

The flow is real time interactive, character by character or in 300 ms time chunks.
Transmission is by RTP with reliability created by RFC 2198 redundancy.

It correspponds to audio and video in real time user experience and is needed to maintain
a good result of a text conversation.

We have discussed to use MSRP in the SIMPLE group for this purpose, but found it too heavy
for real time use. MSRP is for messaging during sessions. rfc2793bis is for real time
conversation during sessions.

Of course MSRP messaging needs to have its end system control as well, so some more words
may be needed to include message oriented media. I hope you look into what is needed for
that mode.

Gunnar

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------

>-----Original Message-----
>From: Xiaotao Wu [mailto:xiaotaow@cs.columbia.edu]
>Sent: Friday, February 18, 2005 3:20 PM
>To: Gunnar Hellstrom
>Cc: iptel@ietf.org; sipping@ietf.org; Toip list; Henning G. Schulzrinne
>Subject: RE: [Sipping] New draft on end system communication services
>
>
>On Fri, 18 Feb 2005, Gunnar Hellstrom wrote:
>
>> I found this to be a good draft.
>>
>> We have a general agreement in the Sipping group that there are three real
>time media that
>> must be considered in all specifications. It is video, text and audio.
>
>Gunnar,
>
>Thank you for the comments.
>Yes, I will put 'text' to the specification.
>The 'text' media type will be for a session based text conversation, like
>using MSRP. SIP MESSAGE method will be handled in Instant Messaging
>extension.
>
>-Xiaotao
>
>>
>> In the Less specification, video and audio are mentioned, but not text.
>> Here are proposals for adding real time text to this specification.
>>
>> I would appreciate if other authors also follow this agreement.
>>
>>
>> ---------------------------------------------------------------------------
>> In section 10.1.1, there is:
>>
>> Parameters:  "media"        A list of medias. Possible values are "audio",
>>                                 and "video".
>>
>> Proposal, I suggest to extend it to:
>>
>> Parameters:  "media"        A list of medias. Possible values are "audio",
>>                                 "text" and "video".
>>
>> ------------------------------------------------------------------------------------
>> Same section 10.1.1, next parameter
>>
>>                  "input"        The source of input. It can be "microphone",
>>                                 for audio, "camera" for video, or a URL
>>                                 to a media file.
>>
>> I think this parameter may need quite a bit of extension, such as "line" as an
>alternative
>> for audio input as well as URL, "line" for video etc. I would expect that you
>also would
>> like to control output, such as headset or loudspeaker for video, screen or speech
>> synthesis for text etc. I leave that for further discussion, when the requirements are
>> more clear,
>>  but just request that you start with adding "keyboard" for text input.
>>
>> Proposal:
>>
>>                  "input"        The source of input. It can be "microphone",
>>                                 for audio, "keyboard" for text, "camera" for video,
>> 					  or a URL to a media file.
>> ----------------------------------------------------------------------------------
>> In section 11.1.2 text should be mentioned among the media.
>>
>> 11.1.2 "Midcall:merge" Action
>>
>>     "Midcall:merge" actions will merge multiple calls into an end system
>>     hosted conference. By default, audio streams will be mixed and sent
>>     to all the call participants. Video streams are forwarded to all the
>>     call participants. If there are held or muted calls, the hold and
>>     mute status are kept.  Their syntax is shown in Figure 14.
>>
>> Proposal:
>>
>> 11.1.2 "Midcall:merge" Action
>>
>>     "Midcall:merge" actions will merge multiple calls into an end system
>>     hosted conference. By default, audio streams will be mixed and sent
>>     to all the call participants. Video and text streams are forwarded
>>     to all the call participants. If there are held or muted calls, the
>>     hold and mute status are kept.  Their syntax is shown in Figure 14.
>> ---------------------------------------------------------------------------------
>>
>> Regards
>>
>> Gunnar
>>
>> -------------------------------------------
>> Gunnar Hellstrom
>> Omnitor AB
>> SWEDEN
>> Mob: +46 708 204 288
>> www.omnitor.se
>> Gunnar.Hellstrom@Omnitor.se
>> --------------------------------------------
>>
>>
>> >-----Original Message-----
>> >From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On
>> >Behalf Of Xiaotao Wu
>> >Sent: Friday, February 18, 2005 1:33 AM
>> >To: sipping@ietf.org; iptel@ietf.org
>> >Cc: Henning G. Schulzrinne
>> >Subject: [Sipping] New draft on end system communication services
>> >
>> >
>> >We have written a new draft on the Language for End System Services (LESS)
>> >
>> >http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt
>> >
>> >This work can be closely related to the SIP P2P work because in a P2P
>> >network, there is no infra-structure to provide communication services,
>> >for example, phone spam filtering. Usually, users will not put their
>> >services on peers' node due to privacy and security reasons. That makes
>> >end system services very important, and it is necessary to define a
>> >mechanism for end system service creation.
>> >
>> >>From the abstract:
>> >
>> >    In Internet telephony, end systems can take a large role in providing
>> >    services, especially in networks without pre-configured
>> >    infra-structure, such as peer-to-peer networks.  Since we believe
>> >    that end system services differ in their requirements from network
>> >    services, we define a new service creation scripting language called
>> >    the Language for End System Services (LESS).  LESS inherits many
>> >    characteristics from the Call Processing Language (CPL).  It contains
>> >    commands and events for direct user interaction and the control of
>> >    media applications.  This document defines the basic elements of LESS
>> >    and several commonly used LESS extensions.
>> >
>> >Suggestions and comments would be appreciated.
>> >
>> >-Xiaotao
>> >
>> >===========================================================
>> >Name      : Xiaotao Wu
>> >Email     : xiaotaow@cs.columbia.edu
>> >Homepage  : http://www.cs.columbia.edu/~xiaotaow
>> >Phone     : (212)939-7054,  Fax: (212)666-0140
>> >Phone-PC  : (212)939-7133
>> >SIP       : sip:xiaotaow@conductor.cs.columbia.edu
>> >Office    : Room 506, Computer Science building, West 120th
>> >===========================================================
>> >
>> >_______________________________________________
>> >Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> >This list is for NEW development of the application of SIP
>> >Use sip-implementors@cs.columbia.edu for questions on current sip
>> >Use sip@ietf.org for new developments of core SIP
>> >
>>
>>
>

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel