Subject: RE: [Sipping] Application Interaction Requirements

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 1 Oct 2002 13:54:02 -0700

David,

Why does this media synchronization have to happen in the application
interaction layer?

It is obvious for (a) & (b) you need some sort of media layer control for
this to work in the first place (speechsc or whatever). Why can you not get
the timestamp information from the media layer directly? As soon as you get
the stop indication you would tell the media control layer: "okay the stop
playing now and remember the last timestmp you played". Then you can restart
playing from that place at a later time - its all in the media control
layer. Likewise for VCR functions.

We are trying to get away from coupled application layers where application
layer stimuli must information such as media signalling. What if the VCR
controls are simply an HTML page and not actual buttons - HTML has
ABSOLUTELY nothing to do with the media and I would like to see the W3C to
agree to such a requirement. 

Robert.

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: 29 September 2002 12:41
> To: Jonathan Rosenberg
> Cc: Fairlie-Cuninghame, Robert; [email-masked]';
> [email-masked]'
> Subject: Re: [Sipping] Application Interaction Requirements
> 
> 
> 
> 
> --On Saturday, September 28, 2002 12:03 PM -0400 Jonathan Rosenberg 
> <[email-masked]> wrote:
> 
> >
> >
> > David R. Oran wrote:
> >
> >>> So, I am inclined to say that these requirements are 
> out-of-scope for
> >>> this
> >>> framework but we wish to open the issue to further discussion.
> >>>
> >> Since I frankly don't understand anything about the second 
> requirement,
> >> I have no opinion (other than it had better get restated so we can
> >> understand it). My opinion on the first requirement is that we
> >> definitely need this (speechsc depends on it), but not 
> with anything
> >> like the interpretation you have.
> >
> > Dave, can you elaborate on the specific need for speechsc? 
> I am confused
> > about this requirement too. My interpretation was similar 
> to Robert's; if
> > you need media synchronization, use rfc2833. Why is this wrong?
> >
> It's not wrong, in fact it works best if you use RFC2833 for 
> tone-based 
> user interfaces. All I'm saying is that the application 
> framework needs a 
> way to obtain timing information from the media stream, and 
> to be able to 
> provide timing information to the playout control of the 
> media stream. This 
> basically boils down to being able to use RTP timestamps to corellate 
> control actions with media processing.
> 
> SpeechSc has at least two specific requirements:
> a) handle barge-in for ASR. The scenario is that something is 
> being played 
> out to the user (e.g. listening to internet radio, TTS output from an 
> application, hearing a voicemail message), and the user says 
> "stop playing 
> this". What you want the system to do is immediately squelch playout, 
> including dumping the  contents of the jitter buffer and 
> discarding any 
> packets in flight when they arrive, and then be able to play "output 
> stopped, next command?" to the user. You can't get a way with 
> just having 
> the application tell the client to stop playout, because then 
> the delays 
> get to be multiple round trips to get output started again. 
> What you really 
> want is the ability for the applciation to say "don't play 
> out anything 
> lower than timestamp x"; then the app can just ensure its 
> next media output 
> has timestamp x+epsilon. For this to work the application 
> framework needs 
> the ability to discover media timestamps and compose commands 
> which take 
> these as data. Also needed are other elements present in or 
> derivable from 
> from RTP, such as SSRCs.
> 
> (Aside: my prefered machinery for barge-in control is RTCP, 
> but this is 
> under discussion in Speechsc and we're not there yet since 
> we're still 
> finishing up the requirements draft. For those interested, 
> you can skim 
> draft-ietf-speechsc-reqts-00.txt).
> 
> b) VCR control. You want the application to be able to say "advance 5 
> seconds" and have that translated to the equivalent RTP 
> timestamp domain so 
> the client can move around in a potentially large jitter buffer.
> 
> This help?
> Dave.
> 
> P.S. I agree with all your comments about focus. From a 
> protocol standpoint 
> however, it is not clear if the right thing to do is to do 
> the real-time 
> event arbitration at the client, or to send the stimulus to all 
> applications and use some meta-control scheme to do the focus 
> control and 
> event filtering at the server end. For GUI or data-based 
> stimulus events, 
> doing everyting at the client is probably a lot cleaner, but 
> for events in 
> the media stream (e.g. tones inband or in RFC2833) the latter 
> may work much 
> better. The reason you really have to remove redundancy from 
> the event 
> stream in the case of media events is for the case where the 
> application is 
> re-constructing the event stream and passing it on as opposed 
> to consuming 
> it. Not properly removing redundancy results is horrible things like 
> double-detection  of DTMF (like adding zeros on the end of 
> the amount of 
> money you deposit in my account :-) ).
> 
> > -Jonathan R.
> >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> 
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: [email-masked]
> 
_______________________________________________
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: Wed, 2 Oct 2002 16:33:04 -0400

I can see registering for a "focus notification" string if all of the
applications are cooperating or forced to cooperate.

Consider the following scenario.  AS1 wants to register for long-# (e.g., a
calling card application).  AS2 wants to register for *T (e.g., a call
center application).

First, we have:

+-----+           +-----+  register for  +------+
| AS2 |           | AS1 |--------------->| user |
+-----+           +-----+     long #     +------+

Then, I can see one of two possibilities.  First, AS2 "gets involved"
(INVITE) with the user, and registers its request.  Second, AS1 INVITES AS2
to "get involved".

First possibility:

+-----+           +-----+  register for  +------+
| AS2 |           | AS1 |--------------->| user |
+-----+           +-----+     long #     +------+
   |                                         ^
   |             register for *T             |
   +-----------------------------------------+

Second possibility:
          INVITE [2]
+-----+ <-------- +-----+  register for  +------+
| AS2 |           | AS1 |--------------->| user |
+-----+ --------> +-----+\    long # [1] +------+
     register for *T [3]  \                  ^
                           ------------------+
                            register for *T [4]

In the first possibility, there are potentials for conflict, attention stack
limits, etc.

In the second possibility, the AS1 acts as a de facto window manager: it
does the arbitration between potentially incompatible registrations.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Steve Fisher
> Sent: Sunday, September 29, 2002 10:04 AM
> To: 'Jonathan Rosenberg'
> Cc: 'Fairlie-Cuninghame, Robert'; 'David R. Oran';
> [email-masked]; [email-masked]
> Subject: RE: [Sipping] Application Interaction Requirements
>
>
> Jonathan,
>
> I agree with everything you say, except your conclusions... In my view,
> our work will be most successful if it enables services that help people
> migrate into the world of rich devices that provide the most compelling
> user experience, and that the most effective approach to achieve this
> goal is to provide access to these services from all devices, even those
> that connect to the legacy telephone network. We would hope that, over
> time, people would increasingly adopt the new devices and abandon the
> legacy devices (and networks). In fact, this is why I'm such a big fan
> of your "markup" draft -- it provides a framework for applications to
> support rich devices while maintaining "backwards compatibility" with
> the touch tone keypad.
>
> I also agree that determining focus is a client problem, and I believe
> the requirement that Eric proposed is simply a mechanism to enable an
> application server to dynamically "register" its application with the
> client, and to enable the client to provide the richest user experience
> it is capable of. In some cases that client, unfortunately, will have no
> inherent interface for determining application focus, and thus requires
> assistance to mediate among the various applications available to that
> device (after all, one of the most exciting aspects of a SIP network is
> the relative ease with which new capabilties are introduced in the form
> of application servers).
>
> Steve
>
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, September 28, 2002 12:02 PM
> To: Steve Fisher
> Cc: 'Fairlie-Cuninghame, Robert'; 'David R. Oran';
> [email-masked]; [email-masked]
> Ultimately, the problem here is the determination of "focus".
>
> Focus is the selection of an application with which the user is
> currently interacting. The proper way to solve this is to provide the
> user with some kind of user interface by which they can select a focus
> in which their stimulus is interpreted. As an example, a web-based
> calling card application would provide the user with an html form that
> they can use to enter their credit card and pin. The calling card app
> gets the focus when the user selects that window. It is clear that the
> stimulus is targeted at that specific application. The client would
> provide its form post directly to the credit card app. There is not even
>
> a hint of a feature interaction problem here.
>
> As another example, consider a phone with buttons on a display. A
> transfer connect app might "own" one of those buttons, such that its
> label is "transfer connect", and once its pressed, the user is told to
> enter the target number and press pound. Once they do that, the
> resulting number is sent ONLY to the transfer connect app, since it had
> the focus for the input.
>
> Now, our problem is that the legacy telephone network has (by todays
> standards) a horrible user interface. One of the problems is that when
> there are multiple applications running, there is no explicit way that
> the user can provide focus. For example, if a voice recorder app is
> running while I am speaking to an answering machine, there are two apps,
>
> each of which is expecting DTMF stimulus. When I press #, who receives
> the pound? Generally speaking, how is focus determined, and by whom?
>
> It is my view that focus can ONLY be determined by the element which
> knows about all the applications which are requesting user input. Thats
> because the focus will need to determined by looking at all of the
> stimulus inputs that have been requested, so as to determine which
> one(s) should and should not receive it. That is the client, NOT an
> individual application. Focus determination is **purely a client
> issue**. Applications should never have any visibility or control of it.
>
> So, how does the client determine focus? If we generalize Steve's
> transfer-connect application, the idea is that each application,
> presumably, has some kind of digit map (in mgcp-speak) which determiens
> the stimulus they are looking for. For the transfer connect app, its
> [*Txxxxxxxxxx]. So, if we assume that there is a set of such digit maps,
>
> Steve's proposal is that focus is determined by a matching process to
> the digit maps of each application. The one whose digit map matches
> first, receives the focus. As a policy, this clearly has problems -
> multiple digit maps may match, and the matching may require too much
> input.
>
> So, I am not convinced that this is the right policy. I'm on the fence
> about whether we even need to specify the policy. Dave, for example,
> might like to apply his patented technique to his phones. I might like
> to build phones with the tabbed display approach I describe below. Can't
>
> he do what he wants, and I, what I want? Why do the applications care?
>
> We may want to recommend or describe a baseline algorithm, though. As
> such, some requirements for it would make sense. Here are the ones I
> would propose:
>
> R-JR-1: The framework must specify a way to determine focus in a client
> when the client cannot explicitly determine focus
>
> R-JR-2: The focus determination algorithm should attempt to minimze the
> delay in providing stimulus to applications
>
> R-JR-3: The focus determination algorithm should attempt to minimize
> false positives, that is, it should aim to provide stimulus to a single
> application at a time
>
> The recipient of the media streams can be considered an application for
> purposes of these requirements.
>
> I don't know what the right algorithm is, and I think we need to work on
>
> it. I am sure that some of the existing work on feature interaction will
>
> be helpful here.
>
> Let me make an additional comment on R-JR-1. The problem at hand here is
>
> strictly a CLIENT problem. An application can still expect pure DTMF
> input, yet the client can provide focus. One can imagine a client
> display with tabs for each app. When you select a tab, any keypad input
> goes only to that app. In this case, the client does have a means of
> explicitly determining focus. Thus, the problem Steve is having is a
> client problem, not an application problem. It therefore cannot be
> solved by an application telling the client to suppress input. The
> client must determine which app(s) to send it to based on information
> from the apps.
>
> Finally, I would like to emphasize that I believe the aim of the
> application interaction work is NOT to design for these dumb phones, but
>
> rather, to design for the smart ones, with UI capabilities, and deal
> with the dumb ones as a special case. I would prefer not to profilerate
> these awful problems into the future.
>
> -Jonathan R.
>
>
> Steve Fisher wrote:
> > I would like to elaborate on Eric's example to help motivate "R2", the
>
> > ability for the network element requesting indications (such as an App
> > Server) to also be able to request that tones be suppressed from the
> > media stream.
> >
> > Consider a "transfer connect" feature, in which one user on a call
> > wants to transfer the call to another device (e.g. from a cell phone
> > to a work phone), and does this by pressing "*T", followed by the
> > phone number for the new device. While it may be necessary to pass
> > "*T" along to the other user, once the user has pressed "*T" the
> > "transfer connect" application server knows that the next string of
> > digits is intended for that application, and the application server in
>
> > that case would request that the user's UA (which may be a gateway,
> > SIP phone, etc.) suppress the remaining digits.
> >
> > In fact, this is exactly how AT&T's existing "Transfer Connect"
> > service works, which is typically used to transfer caller's from one
> > call center agent to another (you may have heard the two tones played
> > when you call an 800 number and are subsequently transferred. Note
> > that you don't hear the destination phone number, since those tones
> > are suppressed).
> >
> > Given that, as you said, "we are building the application interaction
> > requirements and framework from a set of usage cases", we hope that
> > you will agree that this is a reasonable usage case, since it reflects
>
> > one of the most popular "mid-call tone detection" usage cases in use
> > today.
> >
> > Thanks!
> > Steve
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
>
> > Of Fairlie-Cuninghame, Robert
> > Sent: Saturday, September 28, 2002 5:59 AM
> > To: 'David R. Oran'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] Application Interaction Requirements
> >
> >
> > David,
> >
> > Thank you for your comments. See inline responses.
> >
> >
> >>>R1:	For user activity indications, the framework must
> >>
> >>provide some form
> >>
> >>>of indication of occurrence in time relative to one or more
> >>
> >>media streams.
> >>
> >>>I don't believe that this should be a requirement - IF you
> >>
> >>need tight
> >>
> >>>media synchronization then transporting stimulus indications through
> >>
> >
> >>>"out-of-band" mechanisms is not the correct solution for
> >>
> >>your problem.
> >>
> >>Uh, where do you leap from "indication of time relative to the media
> >>stream" to "tight media synchronization". There are lots of situations
> >>which require the former but not the latter. Examples:
> >>- barge-in control in ASR systems
> >>- stream markers in TTS and other playout situations
> >>- speaker change annotations in recording systems
> >
> >
> > David, how do you expect us to get list discussion without making
> > outlandish claims? :) My statement "IF you need tight media
> > synchronization then you should be using RFC2833" still stands.
> However,
> > you are right in saying that the requirement does not imply *tight*
> > media synchronization.
> >
> > We are building the application interaction requirements and framework
> > from a set of usage cases. This application interaction framework is
> NOT
> > designed to solve every application problem in existence - indeed we
> are
> > trying to keep the framework simple whilst covering a reasonable set
> of
> > usage cases. Currently none of the considered usage case require loose
> > or tight media synchronization.
> >
> > If you feel you can provide us with a concrete and compelling usage
> case
> > that requires loose media synchronization, please do so and we will
> > consider it.
> >
> >
> >>>R2:	For key-based indications, the framework must provide
> >>
> >>the ability
> >>
> >>>for the network element requesting the indications to also
> >>
> >>request that
> >>
> >>>the indications be suppressed from delivery to [all] other
> >>
> >>end points on
> >>
> >>>the media path.
> >>>
> >>
> >>I frankly don't understand what this means. For one thing, it seems
> >>inadvisable for one control element to be mandating what
> >>other endpoints
> >>see or don't see. If there is a requirement lurking here,
> >>it's for each
> >>participant to control what they see or don't see of the
> >>control stream as
> >>well as the media stream(s).
> >
> >
> > David in my email I provided a link where Eric originally raised and
> > described the requirement and its motivation. The requirement wording
> > was provided by Eric and its intent seemed reasonably clear to me,
> > however please refer to this email if you are still in doubt.
> >
> >
> >>>There is first the conceptual question: should an
> >>
> >>application be able to
> >>
> >>>modify the media streams without being a B2BUA.
> >>
> >>I'm not sure what this means, because I could modify a stream
> >>and then
> >>re-originate it with a different control protocol other than
> >>SIP, in shich
> >>case I'm modifyng the media stream but I'm not a B2BUA. The important
> >>property is that an application not be permitted to modify a
> >>stream without
> >>being a UA. Otherwise it will run afoul of OPES sooner or later.
> >
> >
> > Ok, ok, B2BUA or UA - it's what I was meaning. My point is that I
> don't
> > think its a good idea for an application to have direct control over
> > another UA or gateway's media (as opposed to peer-to-peer
> negotiation).
> > On the other hand, we could write a protocol to do this; for instance,
> > we could call it a "Protocol for Controlling Gateway Media" (PCGM) but
> I
> > think that some people might realise that this just spells MGCP
> > backwards. :)
> >
> >
> >>>Secondly you quoted a
> >>>usage case such as "* Transfer". The problems I see here is
> >>
> >>that you need
> >>
> >>>to know what numbers the user will pressed before they
> >>
> >>actually press
> >>
> >>>them in order to squelch them.
> >>
> >>Huh? There are lots of ways to eliminate control signals from
> >>the media
> >>path, assuming you know what's going on. I even have a patent on one
> >>technique that avoids introducing extra delay into the media path.
> >
> >
> > And should it be a requirement that everybody implements it? The
> > framework will be extensible, however, we are talking are interested
> in
> > core requirements. Once again, if you have a compelling usage case
> that
> > requires this functionality that is not solvable in other ways, please
> > present it.
> >
> > I think there are better ways of solving this particular problem.
> >
> > Regards,
> >
> > Robert.
> >
> >
> >>>If you simply want you application to stop
> >>>all DTMF digits from being passed through (such as a
> >>
> >>conference server)
> >>
> >>>then is should not have added RFC2833 to start with.
> >>>
> >>out-of-scope for this
> >>requirement, I
> >>have no opinion (other than it had better get restated so we
> >>can understand
> >>it). My opinion on the first requirement is that we
> >>definitely need this
> >>(speechsc depends on it), but not with anything like the
> >>interpretation you
> >>have.
> >>
> >
> > Use [email-masked] for questions on current sip Use
> > [email-masked] for new developments of core SIP
> >

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 9 Oct 2002 09:27:39 -0700

Eric,

> I agree with this completely, but also believe that it is 
> important that
> we balance the need for simplicity with the need to 
> effectively address
> the problems we're trying to solve, one of which (I believe) is to
> enable application servers that require "mid-call DTMF 
> detection" to not
> be directly monitoring the media stream. While the requirements do a
> good job for many such applications (e.g. calling card "force 
> hangup"),
> they do not meet the needs of the "transfer connect" service, which is
> one of the most popular such applications. For that service, once the
> user presses "*T", all subsequent tones are not sent to the other
> phones/devices on the call. As Jonathan pointed out, addressing this
> need raises the general issue of determining focus, which adds
> complexity but is still nevertheless a requirement for this 
> application.
> I also think that we're still pretty far from VoiceXML -- no 
> ECMAScript,
> no TTS, no ASR, simple application logic, etc.

I definitely agree that the problem needs to be solved (and without having
to monitor the media stream), I was just pointing out that a low-complexity
solution exists and may be preferable even though it is not an optimal
solution (in terms of delay and number of messages).

The requirements for the framework are chiefly to drive any new
functionality required - I contend that this usage case can be accomplished
by simply using existing primitives. That's not to say that adding a
requirement of some sort isn't beneficial but I think we need to think more
about the wording so not to railroad a solution.

> I also disagree with the more philosophical point raised below:
> 
> > > My opinion is that it is MORE important that an
> > application can be written
> > > to work equivalently on a smart and dumb device
> 
> My view is that having an application work equivalently on smart and
> dumb devices inevitably leads to a "least common denominator" user
> experience. While developers are always free to build such 
> applications,
> I do not believe that this is the best approach. Instead, a better
> approach is to allow developers to build an optimal user 
> experience for
> each particular class of device. I hope the following 
> examples can help
> illustrate why I believe this:
> 

I completely agree with you - a designer should be able to write
applications to exploit functionality of a smart phone. But that does not
detract from my assertion that it should be possible to write an application
(exercising reasonable set of simple functions) that will work equivalently
on a dumb phone and a smart phone - yes, a lowest common denominator
application. Now obviously, what is really desired is that a lowest common
denominator application is as close as possible to being a pure subset of a
smart phone dedicated application.

Cheers,

Robert.

---

From: Gordon Ledgard <[email-masked]>
Date: Thu, 17 Oct 2002 11:50:56 -0400

Eric, 

Your model is different from what I'm proposing in a couple
of significant repects.

First, I'm proposing that there is a mechanism largely outside of 
SIP to handle this. Second, it is not the responsibility of either
AS to manage the focus. It is the responsibility of a specific
focus-management agent, to which applications consciously subscribe.

I was trying to get all this keystroke arbitration OUT of the
signalling plane altogether.

If you wanted to use SIP syntax as a transport, that would be
great, but the channel between the Event Agent and the apps
would not be 3261. XML, DML, MSCML, MEGACO, paper cups with string,
take  your pick.

Gordon Ledgard
IPeria, Inc.

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, October 17, 2002 10:14 AM
> To: Gordon Ledgard; 'Bert Culpepper'; Steve Fisher
> Cc: 'Fairlie-Cuninghame, Robert'; 'Jonathan Rosenberg'; 
> 'David R. Oran';
> This is the model I proposed in a prior e-mail,
> <http://www1.ietf.org/mail-archive/working-groups/sipping/curr
> ent/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
> > Cc: 'Fairlie-Cuninghame, Robert'; 'Jonathan Rosenberg';
> > [email-masked]; 'David R. Oran'; [email-masked];
> > [email-masked]
> > 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.
> >
> >
> >
> >
> >
> > 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]
> > 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]
>