Subject: [BLISS] Use-Cases for ACH

From: Shida Schubert <[email-masked]>
Date: Thu, 26 Feb 2009 11:24:47 +0900

All;

  Below are the use-cases that have come up so far on
the list and among the design team. We will use these
as a starting point to evaluate REST usage for ACH but
would like more feedback on the use-cases presented
below.

  * Call forwarding unconditional: either to voicemail or to any other  
number.
  * Call forwarding on busy: either to voicemail or to any other number.
  * Call forwarding on no answer: either to voicemail or to any other  
number.
  * Call forwarding when not registered: either to voicemail or to any
other number.
  * Call forwarding when not reachable: either to voicemail or to any
other number.

  * Barring on all outgoing calls: on/off
  * Barring on all outgoing international calls: on/off
  * Barring on all outgoing calls when roaming except to own service
provider: on/off
  * Barring on all incoming calls: on/off
  * Barring on all incoming calls when roaming: on/off

  * Enabling/Disabling anonymous call reject.
  * Enabling/Disabling the ability to reject call when call is  
anonymous.
  * Enabling/Disabling call-waiting
  * Enabling/Disabling voicemail (This is probably equal to the
forwarding Markus presented)
  * Enabling/Disabling DND

  Regards
   Shida

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 27 Feb 2009 14:45:07 -0500

The following list of settings has been proposed.  I'd like to make sure
that there is consensus on the interaction between them.

>   * Call forwarding when not reachable: either to voicemail or to any

My impression is that each of these "call forwarding" conditions can be
set or cleared independently, but that "unconditional" overrides the
other settings, and "no answer" is overridden by "not registered" and
"not reachable" when they are applicable.

> forwarding Markus presented)

Each of the barring and enable/disable settings seem to be independent.

Call-waiting is always implemented locally on the phone in SIP, so I
don't see the need for a SIP ACH function for it.

I originally thought that barring outgoing calls is not sensible for
ACH, because SIP ACH is a user-operated feature and the user has control
of what calls the phone makes, but I was wrong -- the UA can initiate
INVITEs due to in-dialog REFER, and so "barring outgoing" functions
prevent the UA from automatically following REFERs that the user doesn't
want followed.

But it looks like "barring outgoing" functions are all implemented in
the UA, and so aren't an ACH function per se.  ("Barring incoming" needs
to be done at the proxy, so that's an ACH function.)

Dale

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sat, 28 Feb 2009 01:01:25 -0500

Pl. see inline ..

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Dale Worley
>Sent: Saturday, February 28, 2009 1:15 AM
>To: Shida Schubert
>Cc: [email-masked]
>Subject: Re: [BLISS] Use-Cases for ACH
>
>The following list of settings has been proposed.  I'd like to 
>make sure that there is consensus on the interaction between them.
>
>My impression is that each of these "call forwarding" 
>conditions can be set or cleared independently, but that 
>"unconditional" overrides the other settings, and "no answer" 
>is overridden by "not registered" and "not reachable" when 
>they are applicable.
>
>Call-waiting is always implemented locally on the phone in 
>SIP, so I don't see the need for a SIP ACH function for it.

I think it is an ACH feature in the sense that the proxy can decide
whether to extend the call to called party or send 486 otherwise.
 
>
>I originally thought that barring outgoing calls is not 
>sensible for ACH, because SIP ACH is a user-operated feature 
>and the user has control of what calls the phone makes, but I 
>was wrong -- the UA can initiate INVITEs due to in-dialog 
>REFER, and so "barring outgoing" functions prevent the UA from 
>automatically following REFERs that the user doesn't want followed.
>
>But it looks like "barring outgoing" functions are all 
>implemented in the UA, and so aren't an ACH function per se.  
>("Barring incoming" needs to be done at the proxy, so that's 
>an ACH function.)

How about the case where a system administrator sets barring outgoing
calls based on Class of Service for a given user.

Sanjay
>
>Dale
>
>
>_______________________________________________
>BLISS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bliss
>