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 PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
