1. Review of action items from Dublin:
 - Henning Schulzrinne will examine the needs for configuring basic UI
devices (username, password, domain).
        Henning had made some proposals by email (attached), which he
summarised. The emphasis was on consumer-style access. One class of user
devices with a full UI (e.g., a soft client) would operate in a
SKYPE-like manner with an email-style identifier and sign-up via web
page - more a UI issue than a specification issue. Concerns are
consistent labelling and avoiding exposure of unnecessary information.
So action item for SIP Forum would be to write a recommendation of the
UI for use in non-expert mode.
        Discussion: Could try the SIP config framework to start with,
but if it fails could try to register as above using just the 3 basic
parameters (user name, domain and password). Without being configured
with dial plan, still should be able to dial full numbers. May not work
in an ideal manner, but should at least get to point of being able to
make/receive calls.

        The second class or user devices were ATAs (audio terminal
adaptors), i.e., a basic phone, no display (or very limited display),
possible with some interactive audio / touch tone interface.
Configuration framework keying off the hardware ID may work. Need to
associate an account with a hardware ID, e.g., a number printed on the
device that the user keys in via a web page. Just have to type in
telephone number and password, but leaves problem of who is the service
provider. Proposal to use an ATAD-like IANA registry, and then have some
mechanism whereby the ATA can interrogate a server to get mapping from
this number to a domain. SIP Forum would probably need to specify this
mechanism.
        Discussion: Sumanth: close to a CableLabs proposal. Henning:
Would not work if the registry process is expensive, so hopefully a
simple solution based on IANA would be possible. Would Enum be a
solution? Henning: Problem that global Enum deployment is not what we
had hoped for, and also the privacy aspect is a concern, since it could
lead to unsolicited approaches from other service providers to use their
services. An alternative might be to key in a customer service number
and do Enum look-up, to overcome the privacy problem somehow, but still
a concern about the state of deployment of public Enum. Sumanth to post
some further thoughts on the mailing list.
----

[S] The last statement is the reason for this email :)! Here are some
thoughts:
- For the software client, I agree with Henning. If you have a username,
password and domain name, you should be set to obtain a configuration.
- For ATAs, there are multiple ways to solve the issue. I am enclosing a
subset of scenarios that I had explored for CableLabs a while ago (with
some modifications for general usage):

>
Scenario A. The subscriber signs up externally (e.g., web page) and then
wants to associate an off-the-shelf generic ATA with the subscribed
service.

= In this scenario, the web page would provide a 'service provider code'
along with a PIN (you will probably be allowed to select your phone
number at this stage). The subscriber would then dial the 'service
provider code' and 'PIN' into the ATA. This could be via a user
interface, or just the dial-pad. (In fancy ATAs you could have a local
announcement to request this information.) The ATA then connects to a
well-known registry (e.g., IANA, as we discussed) and requests a
translation of the service code into a domain name. This results in
initial configuration that can also provide the device credentials.

The advantage of a 'service provider code' is the concern raised on the
last call that { phone number => domain } mapping raises privacy issues.


>
Scenario B. The subscriber signs up via the ATA.

= In this scenario, the ATA connects to 'generic' hosted site. The site
provides minimal configuration that connects the ATA to an announcement
server. The user connects a phone, goes off-hook, and is connected to
the announcement server that can provide a list of options to the user
(e.g., based on location, based on price, or by asking the user to type
in the first few letters of the service provider s/he wants to connect
to.)

When the user selects a service provider, the ATA is provided with new
configuration that identifies the domain name of the selected service
provider, and further prompts allow the user to subscribe and get
configured with the service provider.


Scenario A is relatively easier to implement (requires a registry),
while Scenario B is relatively complex for the 'generic use case'
(requires config and announcement servers).


http://www.broadband-forum.org/technical/download/TR-069Amendment2.pdf