Subject: RE: [Sipping] Application Interaction Requirements

From: Gordon Ledgard <[email-masked]>
Date: Wed, 16 Oct 2002 10:25:44 -0400

Hi everyone,

I've been horridly busy and just had a chance to catch up on this thread,
so forgive me for being a little late... but I had an idea.

What if we introduced the idea of an independent "Event Agent" into the
picture of
network application control; a separate entity that would be the target and
dispatcher of application events (user phone-key hits)?

Say a person dials into an application which belongs to a federation of
(loosely) related applications. The initial invitiation into any of these
related apps
would result in the 2833 stream of events being directed to an Event Agent.
As the user cascaded into the various applications in the federation the
applications would register with the Event Agent for events which interested
them
according to the convention of the Event Agent.

Applications that are too dumb to deal with such complexity would simply
use the regular 2833 or inband DTMF like days of yore, and stay away from
the
Event Agents altogether.

The Event Agents may be vendor specific, but would preferably follow some
API dictated 
by what you folks are trying to work on here so various app vendors could
program to
the standard and get their applications to work together. But most
importantly, the API to
the Event Agent does not need to be SIP or part of the signalling plane of
the
SIP network at all.

What got me thinking about this was Jonathans comments about "focus" and
what is
really going on in Windows systems. In a windows system, it is really the 
underlying operating system, not the application OR the client, that
determines
focus. Applications "sign up" for events. The client (user) simply states an
intent
by providing key or mouse actions. In the final analysis, focus is always
determined
by the underlying system based on some user input. The analogy for us, is
that the
network infrastructure (but not necessarily the connection signalling plane)
needs
to provide a tool for this "focus" decision.

In the case of telephones, be they smart or dumb, we do not have any sort of
convention
for switching focus (i.e. windows). Think about how the windows system works
when you DON'T have a mouse. The user has to press a defined set of
peculiar,
awkward keystrokes to change the focus to the window they want. An Event
Agent
could provide this standard within a set of interoperating applications
without
forcing all phones or applications to comply, and without adding to SIP
itself.

Any thoughts or flames?

Gordon R. Ledgard
Principal Engineer
IPeria, Inc.

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 11:58 PM
To: Steve Fisher
Cc: 'Fairlie-Cuninghame, Robert'; 'Jonathan Rosenberg';
[email-masked]; 'David R. Oran'; [email-masked];
[email-masked]
Subject: Re: [Sipping] Application Interaction Requirements

I didn't say it directly, but my point is that I feel the requirements 
that Jonathan and Eric seem to have settled on are fine and appropriate 
IMHO.  I also feel that the solution Jonathan began and what I believe 
the design team is working to can fulfill these requirements while also 
not being too much of a burden on application developers to support the 
range of user devices being discussed.  The only burden I see is on 
MGCP/Megaco Call Agents that speak SIP when there are multiple 
applications providing services for a single call.  I don't think we can 
do any better for this case.  It may be that I don't understand Robert's 
concerns (as Robert knows, this wouldn't be the first time I didn't 
understand at first :)

Best regards,
Bert

Steve Fisher wrote:

> I think Bert's suggestion would definitely address my concerns, although
> it applies to the "markup" draft, as opposed to the requirements
> document. I really hope that requirements along the lines of what
> Jonathan and Eric propose make it into the document.
> 

[snip]

_______________________________________________
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
_______________________________________________
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: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:39 -0400

This is the model I proposed in a prior e-mail,
<http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg02981.h
tml>.

Note that the point of using markup is that *where* the markup gets executed
is irrelevant to the application/proxy server.  This is the same model as
X11, where the application thinks in terms of widgets.  The X11 server can
be real smart, and do all of the widget processing locally.  Alternatively,
the X11 server can be real dumb, and only be able to draw lines, circles,
arcs, and text.  In the latter case, many clients interpreted the X11 calls
locally before sending the graphics primitives to the X11 server.

Likewise, the point of the DML/HTML/MSCML model is that focus,
interpretation, and media processing can occur in the User Agent Server or
in a "Phone Proxy" (a.k.a. a media server) that takes the single, in-band
media stream of the User Agent Server (a.k.a. a dumb phone) and serve the
requests from the application server.

> From: Gordon Ledgard [mailto:[email-masked]]
> Sent: Wednesday, October 16, 2002 10:26 AM
> To: 'Bert Culpepper'; Steve Fisher
> Subject: RE: [Sipping] Application Interaction Requirements
>
>
>
>
>
> Hi everyone,
>