Subject: RE: [Sipping] Application Interaction Requirements

From: "Eric Burger" <[email-masked]>
Date: Sun, 3 Nov 2002 10:17:51 -0500

I can see this working if there is only ever one application, and the request is to report all digits, on a digit-by-digit basis.

> -----Original Message-----
> From: Eric Cheung [mailto:[email-masked]]
> Sent: Monday, October 28, 2002 6:41 AM
> To: Fairlie-Cuninghame, Robert
> Cc: Eric Burger; Bert Culpepper; 'Jonathan Rosenberg'; Steve Fisher;
> [email-masked]
> Subject: Re: [Sipping] Application Interaction Requirements
> 
> 
> 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
> 
> 
> 
> "Fairlie-Cuninghame, Robert" wrote:
> > 
> > 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
> 
_______________________________________________
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