Subject: RE: [Sipping] Application Interaction Requirements

From: "Eric Burger" <[email-masked]>
Date: Wed, 2 Oct 2002 16:32:43 -0400

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]

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 02:12:53 -0400

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.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 02:18:13 -0400

Eric Cheung wrote:
> I would be happy with R2 being replaced by R-JR-1, 2, & 3, except that
> R-JR-3 weakens the requirement from "must" to "should". 

Don't read anything into that; this was not an explicit decision to 
change the wording.

> It seems to me
> that it is important that user inputs only go to the application that
> requests it.
> 
> I would propose the following rewrite:
> 
> R-JR-3': The focus determination algorithm must not produce false
> positives, that is, it must provide a stimulus only to the single
> application that is in focus at the time.  This may involve suppressing
> DTMF tones from the audio stream when the media endpoint is not in
> focus.

I think this is reasonable.

-Jonathan R.