Subject: [Sipping] 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
===========================================================

_______________________________________________
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: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 18 Feb 2005 12:23:21 +0100

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.

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
>
>

---

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

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 ;-)

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 ?
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.

More comments later as I digest the rest.

regds
arjun

-- 
Arjun Roychowdhury

---

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

> 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 :-)

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

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?

> 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)

> 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

---

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

---

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
>
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Feb 2005 10:22:31 -0500

Henning, here are some concerns that were reported over time in my
interactions with folks adopting CPL for real life deployment in large
networks.

a) In almost all deployments, lookup addresses sit in some database
(be it in-core or persistent). The issue faced  with CPL currently is
that it ties in a service with where the service needs to go to. While
the former (the service definition) is fairly static and controllable
inside the script, where it needs to be directed to is a function of
the deployment policies/database state of the network. The only way to
'separate' the two is, as you point out, by indirection to an external
URI list. Its much easier instead for programmers to just be able to
dip into their active database instead of having to keep an external
URI list up to date. Infact, I have yet to see anyone really using
this feature in deployment due to this very reason.

Its not often covenient to pollute the database with virtual ids for
the sake of CPL so that the script can have a static address (which is
what a lot of people do today).

One scenario that I keep encountering is the call center business -
they want to be able to route to agents based on rules that identify a
set of people a particular call can go to. This is a factor based on
real-time load, agent availability as well as certain tags they
maintain for agents in their database which are proprietary in nature.

The point is, how the resultant URI list is eventually selected in no
way affects the flow of CPL. Providing an interface to a URI list does
not allow me to dynamically compute a target set in context of that
service flow.

Another area where an application hook helps is active service
monitoring. As an example, today, if a person wants to update a CTI
screen-pop with intermediate status of "I am now trying to reach Mary"
and after 5 rings "User Mary not available, trying Bob" there are only
two ways : a) I intercept the SIP signalling flow - but this is harder
to do as it is 'out-of-context' of the service or b) I use a CPL
extension (which again means its not standard)

At the end of the day, if we allow a mechanism in which the CPL/LESS
script can call an application function , its solves database
integration issues as well as any status/monitoring/state update that
an application may need.

regds
arjun

-- 
Arjun Roychowdhury

---

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

> what a lot of people do today).

Can you explain this a bit more? Do you want to use the same CPL script 
for multiple users?

> not allow me to dynamically compute a target set in context of that

There is somewhat of a fundamental choice to be made here, if I 
understand your model:

(1) Allow a possibly limited set of external functions to populate the 
lookup list. This can probably be made reasonably secure, but is very 
likely to make scripts non-portable across services and servers.

(2) Only have very limited lookup capabilities, as today, making 
portability more likely.

How would you picture the lookup mechanism to look like? An abstract 
function, mapped to a local script? An HTTP URI, but with script 
parameters, such as the request, 'From' and 'To' URIs, as alluded to in 
RFC 3880:

      There has been discussion of having CPL servers add URI parameters
       to the location request, so that (for instance) CGI scripts could
       be used to resolve them.  However, the consensus was that this
       should be a CPL extension, not a part of the base specification.

Thus, it would be something like

http://example.com/script.cgi?from=[email-masked]&to=[email-masked]&uri=[email-masked]

The new draft could be the one providing that extension.

> extension (which again means its not standard)

This does sound like a worthwhile event extension for LESS.

> integration issues as well as any status/monitoring/state update that

I'd like to keep this external interface as well-defined as possible. 
Suggestions on mechanism would help me understand the problem better.

---

From: Arjun Roychowdhury <[email-masked]>
Date: Sun, 20 Feb 2005 11:46:32 -0500

Henning,
Inline.

regds
arjun

> Can you explain this a bit more? Do you want to use the same CPL script

Sorry for being vague on this. An example:

A call center organization wants to route inbound traffic to a set of
agents. However, in this case, the set of agents to route to is not a
"statically defined" group list. Depending on various factors that
occur when the call first comes in (factors include: a) Time of day,
b) agent availability, c) current system load d) Certain propreitary
flags that deal with say, quality analysis of agents - for example,
for training it is required that all agents must at least answer 100
calls in a few hours. so those who are far behind get routed to
sooner) a 'group list' is dynamically created by the call centre
application.

At the end of their business logic (which is a combination of standard
rules (a&b) and non-standard rules (c-d)) they want to provide a list
of URIs that the CPL script must try.

CPL is a perfect application for such a deployment (since a very good
% of their services are routing based). However, what is lacking is
for a mechanism for them
to be able to be able to interact with the script in a more real-time mechanism.

In the above example, the service 'inbound routing' is completely
addressable by CPL - its light-weight (as compared to some other XML
specs). However, the only catch here is that the 'set of routes' that
the CPL script expects is dynamically changing. Maintaining an
external URI list is avoidable - the DB is anyway the source of their
business logic - so one would like to directly seek from the DB.

In the above scenario, just a facility to do a DB dip is enough to be
able to return a qualified list.

I don't want to make it sound like this is only useful for Call Center
apps. Thats just an example that comes to mind. Almost everyone trying
to work CPL into their own service framework face similar issues where
they want to know whats going on at a particular stage (for reasons
that are very varied)

I was extending this concept further - why only a database dip. As I
mentioned in an earlier post, active in-service monitoring is another
need that comes up.

The issue is that in most deployments I have seen, no one really does
_only_ CPL. CPL often forms a part of a larger service framework. As
an example, if one designs a Centrex system, the overall service
framework will comprise of a CPL engine, a B2B engine <and insert your
favourite others: CCXML, CallXML, etc>.
Applications that provide such a  combined service  like to be
'in-the-loop' of what is going on - even if means just notification
(they may want to update a higher level state machine as CPL proceeds
with its steps in the scripts, update certain tracking information,
usage records and so forth).

I have some thoughts on portability later.

> http://example.com/script.cgi?from=[email-masked]&to=[email-masked]&uri=[email-masked]

This is an interesting addition. It does address being able to provide
dynamic target sets at the point of CPL invocation. However, I am not
sure how easy/convenient it would be to provide a large list of URIs
in this mechanism for a target-set. Also, being able to invoke an
API/DB call inside the script is more flexible.

> Suggestions on mechanism would help me understand the problem better.

On taking a look at some other XML based framework, I noticed that
some of them export a "session" object. The object and its attributes
represent the current state of the script. I may be wrong, but if I
understood how this is supposed to work is that the script
specification stops at defining the session object in an abstract
format. How the object maps for a particular implementation differs.
In one implementation, the XML engine may be mapping this structure to
a C struct which the application can 'study' if it needs to.

This would be very useful to have in LESS/CPL too - again, from an
application integration perspective. I dont think it would hurt
portability - the same script could be ported to another system that
implements the backend in a different way - the script does not
change. The way in which the application integrates with the session
object changes - that is a 'backend concern' and is expected.

None of these additions have the power of changing the CPL call flow
or interfering with its execution in a way that CPL does not expect.
Its just a mechanism to make the application more aware of what is
going on.

Now how would this interface look ?
Some ideas:

For uri input:
A db interface would be nice - but I don't know what that does to your
concern of portability.

For app interaction:
expose a session object - specify it in terms of attribute/value
pairs. Let the session object be 'alive' for the life of the CPL
script execution. How does it actually result in the application being
called - does it make sense to introduce a similar event model (but
much simpler) like CCXML ?

It does make the interface more complex. That is a given. On the other
hand, I think this functionality make CPL/LESS easier to integrate
into a larger service framework.

regds
arjun

-- 
Arjun Roychowdhury