Subject: RE: [Sipping] interactivity caller preferences parameter -- for t he dialog package

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 May 2004 17:01:37 -0700

Hi Rohan,

I think such an interactivity indication would be very valuable.

One area where it would be useful is in a Call Center situation.
For example, after a certain amount of time of non-interactivity
listening to elevator music, the call is pushed to a free agent
(through REFER or 3rd party call control for example). It can
also be used for statistics to know how long it takes to 
answer customer inquires, to monitor your agents' efficiency and 
so forth.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Monday, May 10, 2004 11:39
> To: sipping
> Cc: Rohan Mahy
> Subject: [Sipping] interactivity caller preferences parameter 
> -- for the dialog package
> 
> 
> Hi Folks,
> 
> Back in Korea, I presented a proposed solution to the dialog package 
> "hold" discussion which I never described on the list.  It has been 
> several months now, but I would like to describe this proposal now. I 
> am extremely sorry and embarrassed that I have taken so long to send 
> this out.
> 
> The proposal is to add a new caller preferences parameter (these are 
> formally called "media feature parameters" in caller prefs).  The 
> interactivity parameter indicates if a device is capable of 
> responding 
> to media received during a session in an interactive manner and if 
> necessary terminating a session in which the UA is no longer 
> interested 
> in participating.
> 
> For example:
> 
> - If you are in a session with an automaton that does not respond to 
> media nor run call timers (for example a simple recording service, or 
> the "time of day" service in Tokyo Japan), your peer is 
> non-interactive
> - If you are in a session with an IVR-style application or an 
> application with a media inactivity timeout, your peer is interactive.
> - If you are in a session with a human user who just put you 
> "on hold", 
> your peer is non-interactive.
> - If you are in a active session with a human call center 
> agent in most 
> call centers, your peer is interactive.
> - If you are in a normal session with another human, you don't (and 
> can't) know if your peer is interactive or non-interactive.  [This 
> property is quite normal for caller preferences and does not diminish 
> the usefulness of this parameter when you do know its value.  For 
> example, it is unwise to assume that a peer is not an automata, just 
> because the automata parameter is not set; the automata/human 
> status is 
> unknown.]
> 
> What can you do with this information?  (Note that in many cases 
> positive knowledge that a peer is non-interactive has a more 
> immediate 
> effect than positive knowledge that a peer in interactive)
> 
> - This information can be conveyed in the dialog package and used as 
> part of a shared-line implementation.  For example, if a group of 
> phones have all subscribed to the dialog package for the same address 
> of record, they will receive notifications whenever the local contact 
> address changes in any of the dialogs for this address of record. 
> Implementations could use the non-interactive parameter on a 
> phone or a 
> "parking lot" application as a way to indicate that a shared line is 
> "holding" or "parked".
> 
> - This proposed property is also incredibly useful in conferencing 
> scenarios.  A focus can include in the termination policy of an adhoc 
> conference, the interactivity status of the participants.  
> For example, 
> if the only participants in a conference are non-interactive, 
> an adhoc 
> conference is unlikely to be especially interesting (ex: a recording 
> bot and a human who placed the conference on-hold).
> 
> I believe this satisfies all the requirements for indicating 
> if a user 
> is on hold, but captures a more fundamental and generic 
> mechanism/primitive.  I believe that also maintains the "maximum 
> orthogonality among attributes" property of most of the other caller 
> preferences media feature parameters.
> 
> Please comment.
> 
> many thanks,
> -rohan
> 
> 
> _______________________________________________
> 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: "Francois Audet" <[email-masked]>
Date: Mon, 17 May 2004 11:49:19 -0700

Jonathan, 

The "interactivity" is not the same thing as the sendonly/inactive SDP.

First, the application that needs to know the interactivity status of
a UA may not have access to the SDP information (S/MIME, etc.).

Second, it is not related to the presence of media or not. A
user may be "on-hold" at a Call Center, being fed music or an 
announcement.

A Call Center application may subscribe to an Agent interactivity status 
(I personally think a "non-interactivity" status makes more sense).

The Call Center application may be required to monitor the amount of time a 
customer spends on hold, and take action accordingly. Evaluate the
service provided by the agents, re-route calls dynamically, etc.

I agree with Rohan that the interactivity status is on a per dialog
basis, and NOT on a per individual media stream.

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, May 13, 2004 22:56
> To: Rohan Mahy
> Cc: sipping (E-mail)
> Subject: Re: [Sipping] interactivity caller preferences 
> parameter -- for the dialog package
> 
> For the second one, I recall asking at the meeting (thought perhaps I 
> just thought it and didnt ask it) what the difference was 
> between this 
> and the sendonly or inactive SDP attribute, which we've traditionally 
> used for call hold. The fact that I'm not receiving media any more is 
> something that is easy to determine and define, and would by 
> definition 
> make me "non interactive" since I'm not receiving your media 
> in order to 
> make a decision. I think you are concerned about cases where 
> an endpoint 
> has put a call on hold, and has not bothered to disable reception of 
> media. So, my question is, why do that?
> 
> To answer my own question, the main case I can think of is 
> actually nat 
> traversal. If you stop receiving and sending media, you may end up 
> causing timeouts in nat bindings in NATs. You need to keep packets 
> flowing to keep those open for the whole duration of the 
> call. As such, 
> a fine solution is to use an alternative codec for "hold" 
> periods, which 
> causes low packet rates, but enough to keep the bindings 
> open. A no-op 
> RTP payload format has been proposed for this; comfort noise 
> would also do.
> 
> In such a case, you no longer can use the sendonly/inactive as an 
> indicator of hold, either to your peer or in the dialog event 
> package, 
> of the call being "on hold", and in that case you would need a 
> replacement to signal it.
> 
> In such a case, its not clear to me that its actually a callee 
> capability parameter. Those are meant to be more static in 
> nature, and 
> are defined as UA capabilities and characteristics. This is 
> neither, its 
> more like a state for a media stream, perhaps even closer to an 
> indication of usage of a particular codec. Indeed, it would 
> seem to me 
> to be possible to be 'on hold' for some media streams and not others 
> (for example, I still receive your video but not your audio), which 
> would make this hard to do as a callee capabilitiy parameter. 
> Indeed, my 
> "interactivity" would be hard to define in such a case.
> 
> Thanks,
> Jonathan R.