Subject: [BLISS] Configuring the proxy

From: "Elwell, John" <[email-masked]>
Date: Fri, 09 May 2008 08:53:28 +0100

One of the proposed measures for Automatic Call Handling (ACH) is to
standardise the way in which a user can examine and modify ACH settings
at its domain proxy.

One obvious mechanism, and one that is implemented fairly widely I
believe, is simply a web page. The web page would need to authenticate
the user somehow and restrict the user to changing proxy settings
relating to herself (her own ACH settings and possibly other settings).
The user would need to know where to find this web page. A means of
configuring the URL in the UA (e.g., using the configuration framework)
would be useful, but otherwise there does not seem to be a need for
standardisation.

One possible limitation of such a web page is that it is suitable for
use by the user, but not normally very suitable for use by the UA on the
user's behalf. There may be use cases where this is important.

As an example, consider a device with a dedicated button for turning
on/off the immediate redirection of calls to voicemail and a
corresponding lamp to show the current setting. (It does not need to be
a button and lamp - other UI realisations are possible.) When ACH is
performed at the proxy, the UA needs to know the current setting (in
order to control the lamp) and needs to be able to toggle the setting.
Similarly, many other examples could be identified where the UA needs to
monitor and/or control proxy ACH settings in order to provide a
sophisticated UI. Furthermore, the UA might have the intelligence to
monitor/control proxy ACH proxy settings when ACH is provided by the
proxy, but provide its own local ACH on other occasions.

So the first question for the BLISS WG is whether there is indeed a need
to standardise a method (i.e., specify a MUST implement method) by which
a UA can monitor and control proxy ACH settings.

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

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 9 May 2008 19:05:12 +0200

Without having followed the ACH discussion at all. My first reaction to
your question below is, did you consider XCAP?

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Friday, May 09, 2008 9:53 AM
To: [email-masked]
Subject: [BLISS] Configuring the proxy

John

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 9 May 2008 17:08:02 -0500

A SIP configuration framework approach should also be considered.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hans Erik van Elburg
Sent: Friday, May 09, 2008 12:05 PM
To: Elwell, John; [email-masked]
Subject: Re: [BLISS] Configuring the proxy

/Hans Erik

-----Original Message-----

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 13:25:10 +0100

Hans Erik,

Yes, XCAP is one of the candidates. The survey results showed that
respondents used the following:
- web page
- uploading CPL script
- web services
- CSTA
- XCAP

John 

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 09 May 2008 18:05
> Subject: RE: [BLISS] Configuring the proxy
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 13:26:33 +0100

Mary,

Can you clarify how the SIP configuration framework would be used to
configure a proxy?

John 

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 09 May 2008 23:08
> To: Hans Erik van Elburg; Elwell, John; [email-masked]

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 12 May 2008 08:50:05 -0500

John,

I was suggesting to consider the model for the framework in terms of the
fact that some of the data with which a client is configured may well be
data that the client has configured for it's proxy (e.g., SIP Service
Provider (i.e., 'user profile data').  It seems that the types of data
that the client is configured with have some overlap with the sorts of
data you're discussing configuring a proxy with, particularly in your
example of buttons and lamps. Also, don't you get into similar issues in
terms of data overlap (e.g., user versus device versus local-network)?
It seems that all the data you're talking about is what is referred to
in Config-FW as SIP Service Provider, which provides 'user' profile
data. But, don't you have to consider similar deployment scenarios and
the impact of 'device' profiles (i.e., aren't buttons specific to
devices)?  And, wouldn't the "monitor" aspect of what you're discussing
naturally be based on the SIP configuration framework?  

IMHO, it would be nice to have some parallels and similar terminology in
discussing these concepts. 

Mary. 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, May 12, 2008 7:27 AM
To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg; [email-masked]
Subject: RE: [BLISS] Configuring the proxy

Mary,

John 

> Without having followed the ACH discussion at all. My first reaction 
> to your question below is, did you consider XCAP?
> 
> /Hans Erik
> 

> standardise the way in which a user can examine and modify ACH 
> settings at its domain proxy.
> 

> use by the user, but not normally very suitable for use by the UA on 
> the user's behalf. There may be use cases where this is important.
> 
> corresponding lamp to show the current setting. (It does not need to 
> be a button and lamp - other UI realisations are possible.) When ACH 
> is performed at the proxy, the UA needs to know the current setting 
> (in order to control the lamp) and needs to be able to toggle the 
> setting.
> Similarly, many other examples could be identified where the UA needs 
> to monitor and/or control proxy ACH settings in order to provide a 
> So the first question for the BLISS WG is whether there is indeed a 
> need to standardise a method (i.e., specify a MUST implement
> method) by which

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 15:20:26 +0100

Mary,

> Sent: 12 May 2008 14:50
> To: Elwell, John; Hans Erik van Elburg; [email-masked]
> data you're discussing configuring a proxy with, 
[JRE] Yes, there may be some similarity.

> particularly in your
> example of buttons and lamps. 
[JRE] In the sense that on the one hand I may wish to configure a UA to
forward certain calls to voicemail, or, with proxy-based ACH, I may
instead wish to configure a proxy to forward certain calls to voicemail.
I don't see the user interface details (e.g., buttons and lamps) as
being applicable to the proxy.

> Also, don't you get into 
> similar issues in
[JRE] I am not sure where local-network data fits in here.

> devices)?  
[JRE] Yes, buttons would probably be part of a device profile, but I am
not talking about configuring button information at the proxy.

> And, wouldn't the "monitor" aspect of what you're 
> discussing
[JRE] Perhaps the SIP proxy could behave as a configuration server, so
that the UA could subscribe to it and receive updates of the proxy-held
configuration on behalf of me as a user. However, the received
information would not be used to configure my UA (e.g., if the proxy
redirects a certain category of call to voicemail, I don't need to
configure my UA to do the same thing). My UA merely needs to know so
that it can advise me, the user, of the current configuration. Also I
would need a means such that the UA could request, on my behalf, changes
to the proxy configuration. I am not sure that the configuration
framework allows this.

> discussing these concepts. 
[JRE] Yes, it would be nice, but I am not sure how far we can go in that
direction.

John