Subject: [Iptel] New draft on end system communication services

From: Xiaotao Wu <[email-masked]>
Date: Thu, 17 Feb 2005 19:33:16 -0500 (EST)

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     : [email-masked]
Homepage  : http://www.cs.columbia.edu/~xiaotaow
Phone     : (212)939-7054,  Fax: (212)666-0140
Phone-PC  : (212)939-7133
SIP       : sip:[email-masked]
Office    : Room 506, Computer Science building, West 120th
===========================================================

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Feb 2005 09:01:01 -0500

Arjun Roychowdhury wrote:
> Xiaotao/Henning,
> 
> Thanks for the *excellent* draft. It effectively addresses a lot of
> CPL limitations. Even though your draft has the noble intent of
> end-devices, I can see B2BUA providers rubbing their hands in glee ;-)

We'll pursue a "don't ask, don't tell" policy in this regard :-)

> 
> One quick comment: Is it at all possible to provide an interface using
> which a person creating a service  in LESS can do a database-dip to
> resolve a URI ?

CPL has some notion like that, for location lists. Can you describe this 
functionality in more detail? Would you envision the ability to put an 
SQL query in a script?

> Hardcoding URIs into scripts is often very limiting. To make it more
> general, it would be very useful if there was a way in which 
> applications could 'intercept' the call flow of LESS for the only
> purpose of providing 'input' to the next stage.

Something like a reference to an external script? (CPL has a lookup 
mechanism based on URIs; see RFC 3880 (Section 5.2).)

> 
> More comments later as I digest the rest.

Thanks for the comments.

---

From: Xiaotao Wu <[email-masked]>
Date: Fri, 18 Feb 2005 09:20:04 -0500 (EST)

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
> [email-masked]
> --------------------------------------------
>
>
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On
> >Behalf Of Xiaotao Wu
> >Sent: Friday, February 18, 2005 1:33 AM
> >To: [email-masked]; [email-masked]
> >Cc: Henning G. Schulzrinne
> >Subject: [Sipping] New draft on end system communication services
> >
> >
> >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
> >
>
>

---

From: Xiaotao Wu <[email-masked]>
Date: Fri, 18 Feb 2005 09:47:57 -0500 (EST)

> which a person creating a service  in LESS can do a database-dip to

Arjun,

Thanks for the comments!
Yes, we are thinking to extend CPL 'lookup' modifier.
Currently, the 'lookup' modifier has only one non-uri source --
'registration', or a uri-list. For proxy servers, that's usually enough,
but not enough for end systems. The 'lookup' modifier should be able to do
a database-dip to resolve a URI.

> purpose of providing 'input' to the next stage.

In LESS, we defined a variable as 'action.last-action-result' to get the
return value of the last performed action. But usually, actions do not
return unpredictable values (so far, we only have UI:getinput to return
arbitrary values). For predictable action results, we use action
output (e.g., for 'call' action, it has 'accepted', 'busy' ... output) to
handle (branch) call decisions. This way, it's easier for static script
analysis, e.g., feature interaction handling when merging multiple scripts
into one for execution.

Thanks!

-Xiaotao

> regds
> arjun
> On Thu, 17 Feb 2005 19:33:16 -0500 (EST), Xiaotao Wu
> <[email-masked]> wrote:
> --
> Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Feb 2005 08:37:18 -0500

Xiaotao/Henning,

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 18 Feb 2005 12:23:21 +0100

Proposal:

Proposal:

Regards

Gunnar

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 18 Feb 2005 16:12:31 +0100

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

Renathvagen 2
SE 121 37 Johanneshov
+46 8 556 002 03

>From: Xiaotao Wu [mailto:[email-masked]]
>Sent: Friday, February 18, 2005 3:20 PM
>To: Gunnar Hellstrom
>Cc: [email-masked]; [email-masked]; Toip list; Henning G. Schulzrinne
>Subject: RE: [Sipping] New draft on end system communication services
>
>