[BLISS] configuring the proxy for ACH

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss