Subject: [BLISS] configuring the proxy for ACH

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jul 2008 12:20:01 -0400

Here are some thoughts and a proposal on configuring ACH at the proxy.

Its really important to keep in mind that BLISS is about REAL 
interoperability. That means, figuring out what is REALLY causing the 
interop failures for these features (which the survey and follow on work 
have done a good job at doing), and proposing REAL recommendations to 
fix them. To me, REAL means, that this is something that we believe 
folks will actually do, and would actually solve the problem. Our metric 
of success is, if folks implement our specs, you can plug a phone from 
one vendor into a call agent from another and it works for that feature. 
I don't think BLISS should be an academic exercise.

With that in mind, some thoughts:

1. for configuring the proxy with ACH rules, the ONLY things we need to 
consider are those functions which typically have a button or dedicated 
function on the phone/UA. If something is set up via a web page, we 
don't need to standardize interfaces for that. My sense is, most 
endpoints that have built-in keys or embedded code for ACH features are 
almost exclusively limited to call forwarding (with several variants) 
and DND. I don't think anyone is trying to do ToD-based forwarding rules 
from dedicated software in an endpoint. But if folks have examples, 
please bring them out.

2. XCAP *could* be a way to do this - in theory. But if you look at what 
folks have implemented, well xcap is not exactly a resounding success. 
If we mandate that all phones implement xcap to just set call forward, 
and that all call agents/servers/proxies implement it as well - do we 
think they actually would. Being honest here - I dont think so.

3. The problem we're trying to face here - data-oriented client-server 
transactions - this is actually something that the rest of the Internet 
world has been very successful at solving. At this point, I think it 
would be fruitless to mandate something that we have defined (i.e., xcap 
or a new sip mechanism), and instead, let us just ride the wave. From 
what I can tell, where most folks are going for this stuff is the most 
trivial solution possible - and thats REST.

4. And so, my proposal would be to define a trivial REST interface for 
call forwarding at least. SO something like:

POST http://server.com/joe/profile/callforwarding?value=true

and thats it. PUT vs. POST or whatever, we need to find what the best 
practices are in the "web2.0 world" (if you'll excuse the buzzword). We 
provide an interface for turning it on/off, indicating whether it goes 
to voicemail, allow a target for forwarding.

5. DND - for pre-call DND (where you hit a DND button and future calls 
never reach you). I think, in the modern world, DND is really presence, 
and you are seeing more and more presence deployments including a DND 
state. So my suggestion here would be to use presence for this - i.e., 
the user sets their presence status to "DND". We can debate whether this 
is a new state or is the <busy> state, but lets agree on something (most 
folks are using a separate state for this - and we don't have a value 
for it).

6. as a general rule, we should avoid as much as possible RELYING on a 
consistent mechanism for configuring the phone (i.e., config framework), 
for any of our features to work. Again, the REALITY is that endpoint 
configuration is wildly variable amongst implementations, much more 
variable than any other aspect of the protocol set on endpoint devices. 
I don't think that, having IETF recommend to implement the IETF config 
framework for some features to work, will change at all the likelihood 
of that happening in reality.

Note that, I view configuring the phone as totally different from 
pushing data to the proxy (for which I am proposing a REST interface 
above).

I suspect this will all be controversial, but,thats the fun part :)

Fire away.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 21 Jul 2008 13:23:27 +0100

Jonathan,

Thanks for these thoughts. See below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jonathan Rosenberg
> Sent: 18 July 2008 17:20
> To: [email-masked]
> Subject: [BLISS] configuring the proxy for ACH
> 
[JRE] In principle, yes, as long as the mechanism is extensible to allow
more complex rules to be configured in future.

> think they actually would. Being honest here - I dont think so.
[JRE] Agreed.

> to voicemail, allow a target for forwarding.
[JRE] Sounds like a reasonable approach. What exactly would be
standardised? Presumably everything after the server.com element, which
would need to be configured in the UA.
I think the call forwarding would at least need to be extended to cover
some basic conditions, like busy, no reply, DND, and where to forward to
(voicemail could be a default).

> folks are using a separate state for this - and we don't have a value 
[JRE] Are you arguing here for an enhancement to RPID (new state or
substate of busy state)?
Although DND might well be done via presence, this does not prevent a
call arriving during the DND state, and we need some way to handle that
call (i.e., indicate to the proxy that DND is in force, and configure
the proxy to deal with calls in this state in a suitable way, such as
forwarding to voicemail).

> of that happening in reality.
[JRE] Agreed. The present ACH analysis draft only discusses the config
framework in the context of configuring the UA whether to defer to the
proxy, and even then it only uses the config framework as an example.

> pushing data to the proxy (for which I am proposing a REST interface 
[JRE]Understood.

John