[SIPForum-techwg] Feedback on bootstrapping

[Dutkiewicz, Marek]

DHCP is a very useful method to deliver the 'bootstrap server' address
to VoIP devices. However as pointed out below the customer does not
always have the ability to control the content of options (such as 66 or
160) for delivering the bootstrap server address.

In cases where setting it is not possible for a phone installer to
deliver the bootstrap server address in the DHCP option from the primary
DHCP server, a secondary DHCP server can be used to respond to a DHCP
INFORM request from the VoIP device. This 'secondary server' could be
resident on a PC used by the installer or placed onto a machine within
the customer network DHCP domain. In many cases this method could be
easier to implement than creating methods to enter the bootstrap server
address from the UI of the phone (e.g. if it is an ATA).

Regards
Marek

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Sumanth Channabasappa
Sent: Friday, September 26, 2008 4:18 PM
To: techwg at sipforum.org
Subject: [SIPForum-techwg] Feedback on bootstrapping

Folks,

Martin and I discussed the action item regarding the support for
bootstrapping within the SIP configuration framework
(http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15). 

Based on previous discussions, the understanding is that bootstrapping
involves two aspects:
A. How does the client figure out where it needs to go for initial
configuration?
B. How is it provided with identities and credentials for initial
authentication and authorization, if required?


The SIP configuration framework currently includes text to address the
above, but stops short of mandating or recommending specific solutions. 

Section 5.3.1 of the document provides various ways in which a client
can be bootstrapped with identities and credentials: pre-configuration,
out-of-band, end-user-interface as well as using the framework. Within
each of these options it provides some guidance, e.g., one can use X.509
certificates for identifying the client requesting initial configuration
(without pre-configuration when a PKI is used) or an end-user can
provide the necessary information. These methods can be used for both A
and B, above. 

Additionally, it also provides sample scenarios on a per-profile basis.
For example, the local-network profile in Section 5.1.4.1 allows for the
device to obtain a domain name via DHCP. This can be helpful in the case
of enterprise clients where the DHCP server can be influenced by the
service provider. Once this is obtained, the resulting configuration can
provide all the other details.

Martin and I agree that given the scope of the SIP configuration
framework, this is sufficient guidance. Implementations are going to use
one or more of the proposed methods, and the framework will support it.
We validated this by discussing a few planned deployments (that we are
aware of) and the framework meets the needs of the scenarios we came up
with. 

---

In addition to what Martin and I discussed, this group can potentially
take the guidelines within the framework and create a subset of
procedures for reasons such as interoperability. This would be
independent of the action item we took. 

We can discuss both the summary, and other related work on Monday.

Thanks!
- S






_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg