Configuring the proxy

[Elwell, John]

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
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Hans Erik van Elburg]

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: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf
Of Elwell, John
Sent: Friday, May 09, 2008 9:53 AM
To: bliss@...
Subject: [BLISS] Configuring the proxy

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
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Mary Barnes]

A SIP configuration framework approach should also be considered.

Mary.

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

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: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf
Of Elwell, John
Sent: Friday, May 09, 2008 9:53 AM
To: bliss@...
Subject: [BLISS] Configuring the proxy

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
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Elwell, John]

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

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:hanserik.van.elburg@...]
> Sent: 09 May 2008 18:05
> To: Elwell, John; bliss@...
> Subject: RE: [BLISS] Configuring the proxy
>
> 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: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf
> Of Elwell, John
> Sent: Friday, May 09, 2008 9:53 AM
> To: bliss@...
> Subject: [BLISS] Configuring the proxy
>
> 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
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
>

_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Elwell, John]

Mary,

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

John

> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes@...]
> Sent: 09 May 2008 23:08
> To: Hans Erik van Elburg; Elwell, John; bliss@...
> Subject: RE: [BLISS] Configuring the proxy
>
> A SIP configuration framework approach should also be considered.
>
> Mary.
>
> -----Original Message-----
> From: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf
> Of Hans Erik van Elburg
> Sent: Friday, May 09, 2008 12:05 PM
> To: Elwell, John; bliss@...
> Subject: Re: [BLISS] Configuring the proxy
>
> 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: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf
> Of Elwell, John
> Sent: Friday, May 09, 2008 9:53 AM
> To: bliss@...
> Subject: [BLISS] Configuring the proxy
>
> 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
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
> _______________________________________________
> BLISS mailing list
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
>

_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Mary Barnes]

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:john.elwell@...]
Sent: Monday, May 12, 2008 7:27 AM
To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg; bliss@...
Subject: RE: [BLISS] Configuring the proxy

Mary,

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

John

> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes@...]
> Sent: 09 May 2008 23:08
> To: Hans Erik van Elburg; Elwell, John; bliss@...
> Subject: RE: [BLISS] Configuring the proxy
>
> A SIP configuration framework approach should also be considered.
>
> Mary.
>
> -----Original Message-----
> From: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf

> Of Hans Erik van Elburg
> Sent: Friday, May 09, 2008 12:05 PM
> To: Elwell, John; bliss@...
> Subject: Re: [BLISS] Configuring the proxy
>
> 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: bliss-bounces@... [mailto:bliss-bounces@...] On Behalf

> Of Elwell, John
> Sent: Friday, May 09, 2008 9:53 AM
> To: bliss@...
> Subject: [BLISS] Configuring the proxy
>
> 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
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
> _______________________________________________
> BLISS mailing list
> BLISS@...
> https://www.ietf.org/mailman/listinfo/bliss
>

_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss

[Elwell, John]

Mary,
 

> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes@...]
> Sent: 12 May 2008 14:50
> To: Elwell, John; Hans Erik van Elburg; bliss@...
> Subject: RE: [BLISS] Configuring the proxy
>
> 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,

[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
> terms of data overlap (e.g., user versus device versus local-network)?
[JRE] I am not sure where local-network data fits in here.

> 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)?  
[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
> naturally be based on the SIP configuration framework?  
[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.

>
> IMHO, it would be nice to have some parallels and similar
> terminology in
> discussing these concepts.
[JRE] Yes, it would be nice, but I am not sure how far we can go in that
direction.

John
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss