Re: [BLISS] configuring the proxy for ACH

["Elwell, John" <[e-mail]>]

Jonathan,

Thanks for these thoughts. See below. 

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

> 
> 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.
[JRE] Agreed.

> 
> 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.
[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).

> 
> 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).
[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).

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

> 
> 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).
[JRE]Understood.

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