Subject: [BLISS] draft-ietf-bliss-ach-analysis-04 available

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 Jan 2009 14:09:17 +0000

I am reposting this because somehow the tracker gave me the wrong URL
before (03 instead of 04)! The correct URL is below.
-----------------
In accordance with agreements at IETF 73 and the subsequent consensus
call on the list, I have updated the draft as follows:

- targeted at BCP rather than informational;
- added new section 6 "Best Practices for ACH" containing normative
statements, e.g., including use of response codes;
- deleted open issue associated with 480 response code for explicit
rejection / local;
- added placeholder for referencing a to-be-written framework draft on
REST (Jonathan Rosenberg / Keith Griffin)
- added placeholder for defining URL structures for ACH configuration
(forwarding, DND, etc.) and giving examples (in place of existing
material);
- left placeholder for referencing a generic event package for
notifications of resource changes (draft-roach-sip-http-subscribe seems
to be a candidate);
- various editorial tidy-ups.

The draft is available at:
http://tools.ietf.org/id/draft-ietf-bliss-ach-analysis-04.txt

In my opinion, this draft can now be put on hold awaiting progress on
the REST framework and event package work items.

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

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 20:26:56 +0100

Hi,

I'd like to start discussion on ACH configuration so that we can produce something by IETF 74. By ACH configuration I mean a mechanism to enable setting things such as to which number/URI the proxy should forward the incoming call when the user is busy.

I've studied the case a bit and it appears to be that a good starting point would be to use SIMPLE HTTP (call it REST if you like) mechanism to create, read, write and delete a ruleset that looks awfully lot like CPL. In fact, I think we should just take CPL as a starting point  and perhaps just cut some unnecessary features out of it. The main things to figure out would be just where to locate the resource(s). There could be more than one of them if we want to enable things like multiple profiles. I assume each profile would have its own ruleset. And hey, why not borrow the URI structure from XCAP AUID, that would save us from re-inventing that wheel. We could also borrow the extensibility model from XCAP, i.e. using XML namespaces and discovering which of them are supported by the server.

I believe this would be an approach where we could complete something in a reasonable time. Is there any reason why that approach would not work?

I've also looked at other approaches, such as using REST by breaking the dataset into a bunch of resources. One resource could be for instance the target for call forwarding on busy. That approach would work easily for the basic use cases too, but I believe it has two major shortcomings:
  * It is hard to build rules that have multiple conditions (e.g. take UA response ("busy")and time-of-day into account. That requires some kind of a rule language, such as CPL, where you can combine and order conditions and actions.
  * The extensibility model is undefined.

Markus

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 20:55:37 +0100

Hi,

I've looked at ACH configuration requirements and would like to make sure one fundamental set of requirements is addressed.

GSM is the most popular system for mobile telephony with about 3 billion users. So, it is a pretty massive installed base. Eventually that service is expected to be REPLACED by SIP based mobile VoIP. One important missing piece still is how to replace the call handling settings supported by GSM. This is probably going to be a mandatory feature for many deployments, as even if using such settings is not that popular, there is at least some amount of users who use some of them so it'd be hard to just drop them in a commercial deployment.

So, here's a list of settings that virtually every GSM phone offers, hidden somewhere in the depths of the menus:

* 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.

(There's very little difference between the last two cases from user's point of view so it would be fine to combine them.)

The requirement is that there has to be a way to configure these settings on the SIP proxy/B2BUA implementing ACH for the user. At minimum this means 5 (or 4 if we combine) attributes with value "voicemail" or any sip/tel URI, and one attribute that defines the sip/tel URI for voicemail.

Then there are settings for call barring too:

* 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

(The exact meaning of "roaming" in case of SIP is probably undefined, and does not matter if charging is depending where you are attached to the network. However, in some services there might be a difference.)

So, this would mean at minimum that we need to define a way to set 5 boolean attributes.

I believe that whatever BLISS does for ACH configuration, these use cases must be solved in the very first baseline version of the solution.

At minimum we could design an amazingly simple solution to just solve this case. But since this is the RAI area ;) and we do have other requirements (for instance the reqs draft talks about time-of-day or caller identity based rules), I'd suggest HTTP/REST + CPL as a starting point, as I wrote in another mail.

If there is interest, I could write the GSM reqs in a proper brief Internet-Draft in a more verbose way with references to the corresponding GSM specs.

And, as always, a note that 3GPP is too working in this problem space and it would be good to make some progress in BLISS to discourage them from developing their own specific solution.

Regards,
        Markus

---

From: Shida Schubert <[email-masked]>
Date: Tue, 20 Jan 2009 09:55:35 +0900

Hi Markus;

  As for this problem space and possible solution (simple HTTP), I  
have sent
a reference to draft discussing REST along with the consensus of the  
WG from
the last meeting to APP area for a review.

  I do think we should go ahead with the effort despite the outcome  
from the
APP area review, and I think list of requirements that may benefit  
from the
solution is welcome.

  Many Thanks
   Shida

On 20-Jan-09, at 4:26 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Hi,
>
> I'd like to start discussion on ACH configuration so that we can  
> produce something by IETF 74. By ACH configuration I mean a  
> mechanism to enable setting things such as to which number/URI the  
> proxy should forward the incoming call when the user is busy.
>
> I've studied the case a bit and it appears to be that a good  
> starting point would be to use SIMPLE HTTP (call it REST if you  
> like) mechanism to create, read, write and delete a ruleset that  
> looks awfully lot like CPL. In fact, I think we should just take CPL  
> as a starting point  and perhaps just cut some unnecessary features  
> out of it. The main things to figure out would be just where to  
> locate the resource(s). There could be more than one of them if we  
> want to enable things like multiple profiles. I assume each profile  
> would have its own ruleset. And hey, why not borrow the URI  
> structure from XCAP AUID, that would save us from re-inventing that  
> wheel. We could also borrow the extensibility model from XCAP, i.e.  
> using XML namespaces and discovering which of them are supported by  
> the server.
>
> I believe this would be an approach where we could complete  
> something in a reasonable time. Is there any reason why that  
> approach would not work?
>
> I've also looked at other approaches, such as using REST by breaking  
> the dataset into a bunch of resources. One resource could be for  
> instance the target for call forwarding on busy. That approach would  
> work easily for the basic use cases too, but I believe it has two  
> major shortcomings:
>  * It is hard to build rules that have multiple conditions (e.g.  
> take UA response ("busy")and time-of-day into account. That requires  
> some kind of a rule language, such as CPL, where you can combine and  
> order conditions and actions.