Subject: RE: [Sipping] Application Interaction Requirements

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 9 Oct 2002 03:45:13 -0700

Hi,

My concern with the new requirements is a growing complexity for the client
to implement this framework. I think that for this framework to be a success
it must be as simple as possible for both UA manufacturers and application
designers. 

My opinion is that it is MORE important that an application can be written
to work equivalently on a smart and dumb device (by dumb device I am refer
to devices that cannot present focus) than being too caught up in focus
determination, searching and specifying focus templates, focus algorithms. 

DTMF (as an example) doesn't inherently have context and focus. In fact in
most present day applications, the context is actually provided by an audio
stream (such as a message "Please enter you pin number") and not by some
arbitrary markup entity. Also DML is not designed for user presentation of
context - so what good is it to a user that some arbitrary markup is in
focus when there is no presentation of context? Also, is the client going to
autonomously modify media playout just because the focus is on a markup
document (as Eric Cheung was asking for)? Sometimes this is desirable but
sometimes not. So now we have to add focus determination to the media as
well? And what if application needs to suddenly change the focus because
some important event has occurred; what if two applications decide they need
to be in focus? Also on a dumb device there is a very real chance for things
to go terribly wrong - the client may decide that it should (correctly or
incorrectly) change focus which (a) screws things up, (b) may not be
recoverable and (c) there is no way for the user or app server to know what
has just happened. So now app designers will most probably have to write
their applications differently for smart and dumb devices. This is a
complexity nightmare for both the client and the app designer.

My point is that I think that Eric C's problem can be solved in a very
low-tech, non-optimal but probably sufficient way which keeps things very
simple. The App Server is required to re-INVITE or update media (and other
components that don't have inherent context) to artificially (and
explicitly) create focus for these "legacy" interaction modes.  Eg, the
app-server re-invites to stop the end-to-end RFC2833 DTMF stream after *T
has been pressed (it is quite likely that you will want to present the user
with an audible indication that they are in transfer mode in any case). 

As I said, it is not optimal but it is simple. This does mean that you may
need one App Server entity acting as the focus manager for multiple
focus-sensitive applications (Transfer, Conference Control, Call-Parking,
etc) but I don't see this as too much of a problem. 

It also mean that a simple application such as this can be written to work
equivalently on smart and dumb phones (without crippling the extra
functionality possible for the smart phone). I believe this should actually
be a requirement but I can't think of a good way of wording it.

IMO, these are issues and tradeoffs that the design team will have to
carefully consider before proposing a solution. 

One thing is for sure: we don't want to end up trying to implement X-windows
or VoiceXML using SIP headers.

Regards,

Robert.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 7:13 AM
> To: [email-masked]
> Cc: Steve Fisher; 'Fairlie-Cuninghame, Robert'; 'David R. Oran';
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Application Interaction Requirements
> 
> 
> Eric,
> 
> I agree with you completely. This is why I introduced this 
> requirement:
> 
> R-JR-2: The focus determination algorithm should attempt to 
> minimze the 
> delay in providing stimulus to applications
> 
> An alternative algorithm to the one proposed by Eric C. might 
> send the 
> DTMF to all applications until it finds its matched a 
> template provided 
> by one of them; after that, the remainder of the DTMF that 
> matches the 
> template is sent just to that application. This algorithm 
> sacrifices a 
> bit on always targeting a single recipient with DTMF, in exchange for 
> better latency properties.
> 
> -Jonathan R.
> 
> 
> Eric Burger wrote:
> > The thing I don't like about the "hold the tone & look at it first"
> > approaches is that they, by definition, pull the tones out 
> of the media
> > stream AND deliver them "late".  For example, to suppress 
> *8 (transfer), you
> > need to suppress the * to look for the 8.  Then, if the 
> next digit is not an
> > 8 (how long do you wait?), you generate the * and the 
> following digit(s).
> > The problem is, a lot of services are time sensitive.  By 
> the time the
> > device decides it needs to pass the *, the event the user 
> was signaling may
> > have gone by.
> > 
> > A case in point was MCI's Call Assistant.  You only got 3-6 
> seconds to press
> > the *.  If the time-out is in user times (e.g., seconds), 
> you won't get to
> > "star-out".  [Yes, we had interesting UI ways around the 
> timeout, but good
> > things happened if the user was "in time".]
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
[mailto:[email-masked]]On Behalf Of
>>Jonathan Rosenberg
>>Sent: Saturday, September 28, 2002 12:02 PM
> 
> [snip]
> 
>>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.
> 
> [snip]
> 

-- 
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
_______________________________________________
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: Bert Culpepper <[email-masked]>
Date: Wed, 09 Oct 2002 08:50:59 -0400

Hi all,

I believe the DTMF focus problem can be solved for dumb devices by 
basing DML on MGCP/Megaco DigitMaps, using the algorithm Jonathan 
describes.  If I remember correctly, this will address Eric B's concern 
with "hold the tone & look at it first", each application can specify 
digit accumulation or not.

This may not be optimal for all possible service combinations but should 
reduce feature interaction issues to at least what exists today. 
Smarter devices that can manage focus shouldn't be affected.

The ability for app servers to indicate multiple markup languages 
including preferences should reduce/eliminate application implementation 
complexity.

Regards,
Bert

---

From: "Steve Fisher" <[email-masked]>
Date: Wed, 9 Oct 2002 10:48:06 -0400

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.

> manufacturers and application

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 also disagree with the more philosophical point raised below:

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

1) When I worked at Apple, it was common for application developers to
port their apps from Windows to the Mac, maintaining the Windows UI.
While there are lots of reasons for app developers to do this (simpler
development, consistentcy across platforms, etc), the fact is that Mac
users hated these applications, because the users didn't care about
consistency with Windows, they cared about consistency with other Mac
apps. As an example, to address these concerns even Microsoft created a
Mac development organization focused on building apps such as Office and
IE for the Mac that were not clones of their Windows counterparts, but
were true Mac applications (and did so by hiring many of my former Apple
colleagues!).

2) The original philosophy behind the precursers to VoiceXML was exactly
to enable a single application to work both on in a broswer and on the
phone. The designers, however, realized that this simply resulted in
lousy phone applications, and, instead, the right model was to separate
the "presentation" layer from the "application logic" layer, thus
balancing development complexity with the need to provide a great user
experience across devices. Thus, VoiceXML and HTML are quite different
languages, but allow developers to create a compelling user experience
for their particular device, while also allow these applications to
share much of their back-end functionality.

3) The same approach applies to more traditional web development, both
to support the different features exposed by the different browsers,
support different form factors (such as PDAs), as well as supporting
different versions of the application for different languages and
cultures. While a web site could only support the "least common
denominator" HTML features, only support PCs, and only support one
language/culture, the best sites focus instead on building the best
possible user experience for their customers.

It is for this reason that I am such a fan of the "markup" draft -- it
makes it possible for applications to provide the best possible user
experience for the particular device that the user has at that
particular time. Since one of the hallmarks of SIP is that it enables
practically any device to be involved in a real-time communications
session, this is both important and exciting. It also does a nice job of
definining "simple" technical requirements for "simple" devices (i.e.
DML for dumb phones), while also allowing more complex capabilities to
be used when possible (e.g. HTML, VoiceXML, etc.). 

I apologize for the lengthy response, since I think that all Eric and I
are really asking for is a change to the DML spec along the lines of
what Bert desrcibed, as well as corresponding changes to the
requirements spec along the lines of what Jonathan and Eric proposed,
but it seemed that there were more fundamental differences underlying
the resistance to these proposals that I thought were worth addressing.

Steve

--- Bert Culpepper <[email-masked]> wrote:
> >>>The problem is, a lot of services are time
> sensitive. 
=== message truncated ===

---

From: Bert Culpepper <[email-masked]>
Date: Wed, 09 Oct 2002 23:58:12 -0400

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

[snip]

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:41 -0400

This is fine, so long as we don't go too far down a slippery slope.  The
more times I hear "... like H.248", I have to ask myself, "Is H.248 the
right protocol for the job?"  Most of you know where I stand on using H.248
to build applications...

I fully agree with Jonathan that focus is a local, user-configurable matter.
Thus, by definition, IT IS NOT POSSIBLE ON DUMB PHONES.  One can feel free
to emulate focus, but IT IS AT THE APPLICATION, NOT PRESENTATION, LAYER.

> From: Bert Culpepper [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 8:51 AM
[snip]

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:41 -0400

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 6:45 AM
> [snip] So now app designers will most probably have to write

Is this really a problem?

In my mind, what Steve says here is the heart of the matter.  It is
unrealistic to think that you can build a sensible application that has the
same user interface on a Princess(tm) phone as on a xpressa(tm) phone.  In
the former case, the application will say something like "To change focus,
Press 9" or "To transfer, Press *T".  In the latter case, focus is a local
matter, most likely configurable by the user.  Also, a nicely labeled
"Transfer" softkey magically appears.

As Steve points out, the application doesn't have to change, so long as it
can send VoiceXML or MSCML in the latter case and DML or MSCML in the former
case.

> From: Steve Fisher [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 10:48 AM
[snip]