Subject: RE: [Sipping] Application Interaction Requirements

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 17 Oct 2002 08:15:05 -0700

Hi Eric,

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

Thank you Eric, that is a highly succinct way of stating my feelings as
well.

I feel that much of the confusion has stemmed from the way in which Eric
Cheung's "Transfer Connect" problem/requirement has been approached. IMO,
the way in which the usage case should be solved on a smart phone is a lot
different to a dumb phone - pushing the smart phone solution onto a dumb
phone (and vice versa) is not the right thing to do. You can use focus to
solve the problem very elegantly on a smart phone but you can only emulate
focus (at the application level) on a dumb phone. I think this is the crux
of the confusion.

Robert.

_______________________________________________
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 Cheung <[email-masked]>
Date: Mon, 28 Oct 2002 06:40:43 -0500

Hi Robert

I am afraid that we may be drifting too far from the initial
requirement.  Jonathan brought up 'focus', which I think is an elegant
way of conceptualizing this problem.  But it seems it may be causing
confusion here.

The requirement I raised initially was:

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.e. the originating media endpoint suppresses the DTMF tones from the
audio path if someone has requested them.

The focus is between applications (collectively) and the remote media
endpoint.  In this case, the originating media endpoint must at least
know about the focus, and send the tones to the application as
signalling messages, OR send the tone as media to the remote media
endpoint.

The kind of focus in Eric Burger's comment seems to be amongst multiple
applications.  With a dumb phone, focus can be achieved if the DTMF
tones are completely partitioned amongst applications, or in the case
that there are overlap, it can be resolved by the applications as a
classic feature interaction situation.

To address your earlier proposal of a simpler solution:

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

I think the main problem is one of timing - the re-INVITE may not be
acted upon until a few more tones have been heard by the remote end. 
Also the way RFC2833 works, to stop the DTMF stream means also to stop
the entire audio stream to the remote end.  Therefore the user
experience is quite different from what can be expected if the DTMF
suppression/Focus req is adopted.

Thanks
Eric

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 30 Oct 2002 11:07:50 -0800

Hi Eric,

While this is a reasonable requirement for an IP phone for example.  
This is not always technically feasible on gateway devices.  It is 
virtually impossible to completely remove DTMF tones from an inband 
audio stream because you don't know when the tone start or ends until 
it has been playing or not playing for several milliseconds.

Let's not set the bar *too* high  ;-)

thanks,
-rohan