Subject: [Sipping] I-D ACTION:draft-stredicke-sipping-ep-config-00.txt

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 04 Mar 2002 00:30:26 -0500

Folks:
I encourage anyone who thinks SIP UAs are an important part
of a VoIP system to have a good look at this draft which aims
to define the requirements for end point configuration data and
a standard format.  Your input can make this better.  One of the
largest barriors to any significant scale deployment of SIP UAs
will be the ease of configuration.
Cheers

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
        Title           : SIP End Point Configuration Data Format
        Author(s)       : C. Stredicke, I. Butcher
        Filename        : draft-stredicke-sipping-ep-config-00.txt
        Pages           : 25
        Date            : 22-Feb-02

Mass deployment of SIP compliant devices requires a simple mechanism
for configuring and maintaining them. For the economical success of
SIP based devices on a large scale, a platform independent mechanism
for finding and exchanging the required information is vital. The
goal of this draft is to reduce the amount of effort required for
administrators to provision devices. This draft focuses on defining
a common data set to configure SIP end points. The mechanism for
providing and maintaining the configuration data to the end point is
defined elsewhere [7].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stredicke-sipping-ep-config-00.txt

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 4 Mar 2002 17:49:09 -0600

I must admit sort of a general discomfort with the proposal. My concern is,
standards on how we configure an endpoint by necessasity create constrains
on endpoint capabilities, metaphors, etc. Any attempt to define the core
attributes of an endpoint outside of some application domain strikes me as
not very useful.

For example, the draft seems to be considering an application domain made up
of SIP endpoints that are intended to preserve a "phone-like" user
experience. The market may indeed limit sip endpoints to those that fall
within that application domain, but the working group should not.

Now, if we wish to create requirements for various application domains, e.g.
"things that act like phones", "bandwidth constrained mobile devices",
"video conference systems", "multiplayer games", etc, I think would have a
higher probability of success. (Or at least we would do less unintentional
harm)

Failing that, the first requirement would be to describe how to configure an
arbitrary set of attributes, and leave the definition of those sets to some
sort of profiles.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Daniel G. Petrie
> Sent: Sunday, March 03, 2002 11:30 PM
> To: [email-masked]
> Subject: [Sipping] I-D ACTION:draft-stredicke-sipping-ep-config-00.txt
>
>
> Folks:

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 05 Mar 2002 01:37:26 -0500

I think your point on application domains is a valid one.  We
have certainly focused on configuration that effect the phone-like
behaviors.  One of the outstanding issues was what about presence
and IM.  One could argue that  rigid domains or segmentation of
data categories will inhibit innovation.  Some of the interesting
applications might be the blurring of domains.

As an UA vendor I am also very sensitive to differentiation, innovation
and creativity.  The last thing I want to do is create a flat commodity
based product space for SIP UAs.  However I feel the pain
of my customers who have heterogeneous UA environments.
I am frequently hearing the refusal to deploy anything beyond
trial volumes of USA with out a stadard means to configure
and deploy them.  I think that we have tried very hard to
allow extensions and creativity in configuration.  This is a
delicate balance all standards should try to achieve. We
are certainly open to ways we can improve the openness of
the configuration mechanism.

I appreciate your input.
Thanks

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Mar 2002 08:43:38 -0500

One of the things that I had suggested was to separate configuration
into protocol name spaces, possibly defined in separate profiles
alongside that protocol. That way, a device is simply defined by the set
of protocols it uses and thus can be anything from a traditional phone
to some kind of Internet "appliance" to a SIP-enabled microwave oven.
This would also argue in favor of removing terms like "line" and finding
more generic notions of having multiple protocol instances in one
device.

The configuration draft would then only describe means of describing
groupings.

Automating configuration of all kinds of end systems is crucial; neither
ACAP nor DHCP quite fit the bill.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 5 Mar 2002 09:20:00 -0600

One approach might be to first define the method or methods for telling an
endpoint about an arbitrary set of parameters. Make your current list of
parameters more into a set of example scenarios that justify the
requirements of an arbitrarily extensible configuration method. Of course,
even this mechanism may need to vary by domain.

Then build profiles of recommended parameters for specific application
domains. Support of specific profiles would be entirely optional from the
specification perspective, but perhaps not so optional from a market
perspective.

> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:37 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Sipping] I-D
> ACTION:draft-stredicke-sipping-ep-config-00.txt
>
>
> > > From: [email-masked]
[mailto:[email-masked]]On Behalf Of

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 05 Mar 2002 11:32:26 -0500

Sorry, I it seems that I missed your point of protocol profiles.  I thought
that you meant transport protocols within the SIP domain (i.e. UDP,
TLS, TCP).

I guess that one of the main reasons to have the line construct is to
normalize the data.  I think in most cases there is a common set of
configuration data which is shared across lines (e.g. out bound
proxy, call handling behaviors such as call waiting, do not disturb,
etc., local SIP port(s),  dialing plan, etc.).  Taking the contents of
the line configuration and making each a complete (virtual) SIP
UA instantiation will replicate a lot of the configuration data which
should actually be linked together.  In the most common case a
line is just an address-of-record,  some associated credentials
and a flag indicating whether to register or not.

Is this perhaps just an issue with the name "line"?  Should this
be called something else like "aor"?  I can cerntainly see the
potential to associate other SIP application specific data with a
line/aor.  For example presense information access control:
who is allowed to subscribe to presense state info for a particular
line/aor.

We could create an line/aor container which has property sets associated
with specific application domains (e.g. phone, presence, microwave, etc.).
We could create containers for each of these domains having some
well defined properties, but also leaving it open for extension and
inovation.  If we allow these property sets to be applied accross all
lines/aor's or to a specific line/aor we have fairly normalized data
and well contained domain data.  Does this solve the requirement or
am I still missing the point?

To illustrate in XML:

<user>
    <phone>
          <! phone configuration common to all lines/aor's>
          <call-waiting max=3>
    </phone>
    <aor>
         <url>Fred&ltsip:[email-masked]&gt</url>
         <phone>
                <! phone configuration specific to this line/aor>
                <registry type=register>
                <forward-on-no-answer>
                      <url>sip:[email-masked]</url>
                </forward-on-no-answer>
         ...
         <\phone>
         <presence>
            ...
         </presence>
    </aor>
    <aor>
         <url>Fred Smith&ltsip:[email-masked]&gt</url>
    ...
    </aor>
...
</user>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Mar 2002 11:45:42 -0500

> that you meant transport protocols within the SIP domain (i.e. UDP,

No, I meant in general, as in (pardon my XML)

<sip>
 <sip:aor>[email-masked]</>
 <sip:t4>138</>
</>

> etc., local SIP port(s),  dialing plan, etc.).  Taking the contents of

That's what XML grouping seems designed for.

> and a flag indicating whether to register or not.

Indeed; they can all be "inherited" from the enveloping description.

> who is allowed to subscribe to presense state info for a particular

Avoiding names that trigger too-close an association with black phones
would seem helpful, as SIP "lines" aren't really the same thing as lines
on a keyset.

> am I still missing the point?

As much as possible, I'd avoid descriptions of devices that are not
relevant. You're configuring protocol or UI behavior, not something that
a human would recognize as a phone-like device.