Subject: [BLISS] ACH configuration use cases

From: "Theo Zourzouvillys" <[email-masked]>
Date: Sat, 6 Sep 2008 03:06:26 +0100

Hi,

One of the outcomes of today's ACH design team call was that we would
ask the BLISS list for use cases that ACH configuration may provide a
solution for so we can extract a requirements document for the
configuration format itself.  So, to get the ball rolling, mentioned
today was:

Alice has 2 UA's registered on a single AOR.  One is on her desk at
home, the other at work.  When she puts her phone at work on DND for
all calls, the DND lamp on her phone at home would automatically
detect this and light up the DND lamp.

and I'd also like to add this case:

Bob has somehow pre-defined 3 different "call profiles": one named "In
a meeting" which will divert all calls to his voice mail account.
Another profile - "At desk" - will accept all incoming calls and send
to any bindings registered against his AOR.  finally, the profile
named "Out of the office" will forward all calls to his mobile phone,
sip:[email-masked].  Any SIP UA that registers against bob's AOR (or
indeed, any 3rd party with sufficient permission - e.g, bob's PA)
should be able to display the currently active profile (for example
"At desk"), as well as provide a list of available profiles, and
change the currently active one.

If you have a use case in mind, please let me know!

Kind regards,

 ~ Theo
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 Sep 2008 08:27:01 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Theo Zourzouvillys
> Sent: 06 September 2008 03:06
> To: [email-masked]
> Subject: [BLISS] ACH configuration use cases
> 
> Hi,
> 
> configuration format itself.  
[JRE] Just to be clear, we are talking here about means by which the UA
can configure the proxy. We are not talking about how to configure the
UA (the SIPPING UA configuration framework and profiles work provides a
way to do that). We are not talking about how a user directly configures
his proxy (a web page would do that). We are talking about how a UA
configures its proxy or obtains configuration information from its
proxy.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 08 Sep 2008 08:40:13 +0100

The following use cases are conceivable. They get progressively more
complex, so I don't know where we need to stop. 

1. Carol's UA wants to know when the proxy is configured to forward all
calls to voice mail (so that it can display this information to Carol)
and wants to be able to change this setting in accordance with Carol's
instructions.

2. As above, but forwarding is to a destination that Carol has chosen,
rather than to voicemail.

3. As above, but forwarding is to take place only under certain
conditions, e.g., busy or no reply.

4. As above, but forwarding is to take place only at certain times of
day / days of week.

5. As above, but forwarding is dependent on the identity of the caller.

6. As above, but with different forward-to destinations depending on the
particular conditions.

etc.

John

---

From: Shida Schubert <[email-masked]>
Date: Wed, 17 Sep 2008 12:44:08 -1000

All;

I understand you are all busy with your day job, but I would
like to encourage people to read the following text along with
that of John's comments and provide some feedbacks even
if it's simply expressing an agreements.

Design team needs your feedback to make progress and
to properly scope their task on this.

Many Thanks
Shida (As Chair)

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Sep 2008 13:40:33 +0200

Other use cases could be:

Use case "Call Forwarding":
Bob has activated call forwarding in the following manner:
- If he is at a meeting (presence-status meeting) and his boss calls him, the call should be forwarded to his secretary.
- If his wife calls and he does not answer the call, the call should be forwarded to his daughter.
If this feature is activated / deactivated, the other terminals of the user should get a proper notification.

Use case "Do not Disturb":
Alice has activated do not disturb on her mobile phone in the following manner:
- Incoming calls are still forked to other terminals of Alice (e.g. fixed line terminal)
- If her boss calls, the call will be forked to all of her terminals, including the mobile phone.

Use case "Call Barring":
Peter has activated call baring in the following manner:
	- if he is at a meeting (precence-status meeting) or local time is before 6:00AM or after 8:00 PM
	- and the caller is neither a member of his family nor his boss.
If this feature is activated/deactivated , the other terminals of the user should get a proper notification.

Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von ext Shida Schubert
Gesendet: Donnerstag, 18. September 2008 00:44
An: [email-masked]
Betreff: [BLISS] Need feedbacks on > ACH configuration use cases

All;

Many Thanks
Shida (As Chair)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Sep 2008 04:04:03 +0100

In response to both Theo's and Christian's use cases, I think we have to clearly differentiate between ACH and presence. Setting and monitoring a profile such as "out of office" or "in meeting" or "DND" is very much like presence publishing and watching. Where ACH kicks in is the treatment of calls when such a condition exists, e.g., if in "out of office", forward my calls to cellphone or to voicemail. Also as part of ACH a UA needs to be able to monitor whether forwarding is set and under what conditions/profiles it would be invoked, but we can use presence to see whether a profile is activated. Does this make sense?

John 

> On Behalf Of Schmidt, Christian 1. (NSN - DE/Munich)
> Sent: 18 September 2008 12:41
> To: ext Shida Schubert; [email-masked]
> Subject: Re: [BLISS] Need feedbacks on > ACH configuration use cases
> 
> - If he is at a meeting (presence-status meeting) and his 
> boss calls him, the call should be forwarded to his secretary.
> If this feature is activated / deactivated, the other 
> terminals of the user should get a proper notification.
> 
> 	- if he is at a meeting (precence-status meeting) or 
> local time is before 6:00AM or after 8:00 PM
> If this feature is activated/deactivated , the other 
> terminals of the user should get a proper notification.
> 
> Regards
> Christian Schmidt
> 
> 
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Sep 2008 23:42:33 -0400

John,

> In response to both Theo's and Christian's use cases, I think we have to clearly differentiate between ACH and presence. Setting and monitoring a profile such as "out of office" or "in meeting" or…

I agree with you that there is a tight coupling here.
It makes good sense to view the ACH as actions driven by a policy which 
is in turn parameterized by presence status. Mostly you should then just 
need to see that your presence status is accurate, and the ACH should 
follow. (I would think that most people would rarely need to change the 
policy itself.)

But I don't follow your idea that the "profile" itself would be presence 
state.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Sep 2008 19:50:51 +0100

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 25 September 2008 04:43
> To: Elwell, John
> Cc: Schmidt, Christian 1. (NSN - DE/Munich); ext Shida 
> Schubert; [email-masked]
> > In response to both Theo's and Christian's use cases, I 
> think we have to clearly differentiate between ACH and 
> presence. Setting and monitoring a profile such as "out of 
> office" or "in meeting" or "DND" is very much like presence 
> publishing and watching. Where ACH kicks in is the treatment 
> of calls when such a condition exists, e.g., if in "out of 
> office", forward my calls to cellphone or to voicemail. Also 
> as part of ACH a UA needs to be able to monitor whether 
> forwarding is set and under what conditions/profiles it would 
> be invoked, but we can use presence to see whether a profile 
> is activated. Does this make sense?
> 
[JRE] Perhaps I didn't express myself too clearly, but I think we are
agreed that there is a line to be drawn between presence and the ACH
action taken as a result of a particular presence condition. The UA
needs to be able to monitor and control the ACH action to be taken.

John