Subject: RE: [Simple] Data model - attempt at summary (Groups)

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Thu, 21 Oct 2004 17:42:50 -0400

Johnathan -

OK, so then a <person> represents a user level representation of 
an individual, a group, a Bodt, an application, etc.  The idea being
that
a watcher interacts with any of these entities (can't think of a better
word here)in the same way.  From the watcher perspective it doesn't know

if it is communicating with/watching a human user, a Bodt, or a group.
All watchable entities present the same interface.  This makes sense.
I just find calling all these presentities a <person> a bit misleading.
Now that I get it, I am sure I will get used to it...

Dave

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Thursday, October 21, 2004 5:18 PM
> To: Boyer, David G (Dave)
> Cc: Henning Schulzrinne; Simple WG; Mataga, Peter Andrew (Peter)
> Subject: Re: [Simple] Data model - attempt at summary (Groups)
> 
> 
> 
> 
> Boyer, David G (Dave) wrote:
> > Johnathan,
> > 
> > I think the problem is we are saying that a "person" can really 
> > represent an entity that is not a person.
> 
> Right. But there is nothing that we can do anyway to prevent that; i 
> can't force someone to use the <person> construct to only 
> model a single 
> person.
> 
> 
> What has been discused so far
> > concerning groups are
> > - a group can represent a list of users (this is not 
> appropriate for 
> > the <person> object in the model)
> 
> Right.
> 
> > - or a group can represent an "entity" that is the sum of it's 
> > constituants, I guess it is not necessarilly the sum, could be a 
> > union, but it represents something unique in it's own 
> right, kind of a 
> > meta object.  A call center
> > entity represents the capabilities of it's group members.  
> There may be
> > no single 
> > group member that has all that capabilities that the call 
> center object
> > has.  The
> > call center object is unique in that sense and also may have unique
> > contact URIs
> > so that no member's contact information is exposed.  
> Calling this entity
> > a <person>
> > is confusing.  I keep using the word entity to describe this, more
> > generic
> > than person I guess.  If we call it an "entity" - an entity could
> > represent a person, 
> > a group (in the sense of something unique in it's own right), an
> > application, a bot,
> > etc.  Just seems that what we are talking about here is more than a
> > person.
> 
> No, it is a person from a model perspective. That is, the 
> watcher will 
> think it is a person, and nothing in the presence document will (or 
> should) clue the watcher into the fact that this person is really a 
> meta-person that is merely a facade around a group of users.
> 
> I'm not sure if you are proposing rather that we change the name to 
> <entity>; that is sufficiently vague to make it not clear what we are 
> trying to model. We are trying to model states of a single person 
> relevant for communications. Thus, <person> is the right thing.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                        FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Thu, 28 Oct 2004 17:58:37 -0400

Paul -

Very interesting comments/thoughts -
my comments in-line

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, October 22, 2004 4:03 PM
> Cc: Jonathan Rosenberg; Simple WG; Mataga, Peter Andrew 
> (Peter); Henning Schulzrinne
> David - more inline comments.
> 
> 	Paul
> 
> >>Applying presence to call centers presents some unique challenges:
> >>
> >>- Attempting to represent every call center agent as part of the
> >>   presence status would generally not be considered acceptable
> >>   to the call center management, it would present performance
> >>   problems, and it wouldn't provide any utility to an outside
> >>   watcher.
> > 
> > If the group represented every call center agent this would 
> be a "list 
> > style group", something the <person> model doesn't support.
> 
> This could be represented by treating every call center agent 
> as a tuple 
> (service) of the presentity representing the call center or 
> skill group.
> 
> But there are limitations to that approach - it doesn't fit 
> the model. 
> For instance you can't represent the person attributes of each agent, 
> which would include things like language capabilities and possibly 
> extensions for subject matter expertise.
> 
> I don't think this is a problem because the call center would 
> never want 
> to expose addresses of individual agents.
> 
> > If the call center group was a meta object that, in a sense, 
> > summarized the capabilities of available agents, the watcher would 
> > know what forms of communications were available to it, but not the 
> > specifics of a given presentity.
> 
> Yes, that is what I intended.
> 
>  > As an example consider the case where a call
> > center, at a given point in time, has 50 agents available 
> for a voice 
> > consultation and 30 for IM communications.
>  > Through the merging operation of the Composition process,
>  > the voice services of the agents could
> > be replaced by a single service URI that provides a single point of 
> > contact for all voice capabilities, similarly a single URI could be 
> > used to provide indirection to the call center's IM capabilities.
> 
> You seem to be assuming that agents only do one or the other. In some 
> cases that may be true, but it need not be.
> 
> In fact the capabilities can be dynamically determined by an 
> algorithm, 
> such as:
> - Agent 1 can only do voice - max of one call at a time
> - Agent 2 can only do IM - max of 3 sessions at a time
> - Agent 3 can do one voice session or up to 5 IM sessions,
>            but not simultaneous voice and IM
> - Agent 4 can do up to one voice plus one IM session, or
>            two IM sessions without voice. A session with
>            voice may also include IM.
> 
> The capability of each agent needs to be recomputed each time 
> something 
> changes. This might be by the agent's UA, or by something in the call 
> center router. These results can then be rolled up in a 
> manner such as 
> you suggest, though there may be more combinations and so 
> more contacts.
> 
> But the value of doing this is questionable. In a loaded call center 
> agents will not remain available for long, and so the rolled up state 
> will typically not show availability long enough to be useful to a 
> watcher. You just can't expect to call a call center and get 
> immediately 
> routed to an agent. Even when agents are available it is 
> possible that 
> you will be sent to an IVR first to gather some information.
> 
> It is probably more practical to represent the combinations of 
> capabilities that are potentially available, together will an 
> availability indicator of some sort that indicates expected wait time.
> 
> Related to this is a potentially serious problem in using 
> presence with 
> a call center: real callers are entered into a queue, so as 
> time passes 
> they are more and more likely to be assigned to an agent. Presence 
> watchers on the other hand are simply waiting for a time when 
> they can 
> call and not have to wait. They aren't queued, so those who 
> call without 
> watching keep going ahead of them. There well may never be a 
> good time 
> to call.
> 
> To deal with this one might consider doing something special with 
> watchers - enqueuing them, and reporting better availability 
> to those at 
> the head of the queue. But this presents all sorts of ugly 
> problems, and 
> seems like a generally bad idea.

Presenting a watcher with the current state of the call center group
gives the watcher some indication of how long he might have to wait
until he actually will be able to speak (or IM) with someone.  If the
watcher elects to send an Invite to the call center group, he will be
connected to the Call center UA and, likely, be forwarded to a music
on hold server (not sure of the details how this would work).
Isn't it an application level decision as far as actual agent routing
goes?  The Call center application would maintain the queue and use
call center agent presence (as well as the host of other data, as you
pointed
out, that goes into call center routing calculations) to calculate which
agent
should be made available to the next customer in the queue.  Doesn't
the call center than use a Refer to connect the customer to the agent?

> 
> > A voice and IM pivot could be used to accomplish this.
> > I realize this wasn't Johnathan's intent when he proposed 
> the merging 
> > step in the data model, but it represents what the call 
> center would 
> > want in this case.  A single contact URI for voice services 
> which is 
> > resolved to a specific agent when a watcher requests a 
> communication 
> > to the call center.
> 
> I don't think this is a merge operation among publishers at all.
> 
> I think there must be a special call center router that 
> assigns callers 
> to agents. It could be a proxy, but with an algorithm much different 
> than a standard proxy.

Do you agree that this is an application level decision?
> 
> And it *could* use presence published by the agents to guide 
> this. But 
> in that case I don't think the presentities that the agents 
> publish to 
> are the same ones that the are available to users to 
> subscribe to. The 
> relationships are much too complex for that.

Agreed
> 
> >>- as you mention, the call center can have special kinds of
> >>   capabilities that shared equally by all the agents in the
> >>   call center. These groupings are often called "skill groups".
> >>   If you are going to expose the call center via presence, you
> >>   may want to expose each skill group as a separate presentity.
> > 
> > 
> > Good idea.
> > 
> >>- The status of a skill group can't be represented accurately
> >>   by the status attributes currently defined. For instance
> >>   availability vs idleness is not even close to binary - it is
> >>   statistical - measured by something like average wait time.
> >>
> > 
> > Call centers have very sophisticated agent routing rules that take 
> > into acount many things (customer priority, customer 
> history, specific 
> > product info, etc).  This is basically an availability calculation 
> > that might be able to be performed when Privacy Filtering is done. 
> > Granted it is pretty advanced filtering.
> 
> See comment above.
> 
> >>In spite of these problems, I think it will eventually make
> >>sense expose 
> >>the status of call centers via presence. But I think that can be a 
> >>follow-on activity.
> > 
> > You are probably right that this needs to be a follow on, but it is 
> > probably good to think through some of the issues at this point.
> 
> As you can probably tell, I have thought about it. But I 
> decided it is 
> sufficiently special purpose that I couldn't justify delaying the 
> current work to deal with it. (In any case I wouldn't be 
> allowed to get 
> away with that.)
> 
> I think the current work provides sufficient mechanisms to be 
> adapted to 
> call centers, at least enough for awhile. Once the existing work 
> stabilizes there will be opportunities to do more.
> 
> 	Paul
> 
>