Subject: [Sipping] aproposal for simplification in the configuration framework

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Aug 2005 03:53:25 -0400

I was re-reading the latest config profile documents (the dataset work 
in particular) last night, and I really think we need to revisit some 
aspects of the design.

This whole thing has gotten really complicated, all due to the desire to 
support merging operations. I view the configuration framework as the 
most important work in sipping, and the second most important for sip 
overall (the first being nat traversal with ICE and sip-outbound). I 
think it is FAR more important that we get something done that simple, 
solves 90% of the cases, and is implementable without much complexity. I 
fear that the current solution does not meet those goals.

I understand the driving factors behind the merging aspects of the 
configuration framework. I'd like to make a proposal for an alternative 
approach which allows for merging but simplifies things.

Ultimately, any kind of merging operation requires a single element to 
perform the merging. In the current draft, the UA does the merging. I 
think the UA is actually the worst place to due the merging, since it is 
most ill-equipped to understand what the right policies are to guide the 
merging operation. To solve this, the framework makes it the burden of 
the specification of the dataset itself to define how its done. I think 
thats wrong, since the decision on how to merge may be a function of the 
source of the data (trust data from certain hotels, but not from others, 
for example).

As such, I would propose that the merging operation become the problem 
of the domain associated with the subscribers AOR. The idea is the 
following. When the client starts up, it subscribes any local config 
server it has learned about through DHCP or whatever. That server 
returns the configuration parameters that the local authority wants the 
device to use. Then, the UA subscribes to its "main" configuration 
server, the one provided by its service provider. However, it also sends 
a PUBLISH message to that server, containing the profile data learned 
from the local config server. The service provider's config server will 
perform a merging operation, just like a presence server performs 
composition. The configuration profiles coming back in the NOTIFY 
contain the merged profile. The UA always uses the profile returned from 
that config server - period.

As a consequence, the merging operation becomes equivalent to the 
composition policy of the config server. We no longer need to specify 
rules for it, or really even discuss it much. The device get simpler - 
it just uses the profile from its service provider's config server. It 
PUBLISHes any other profiles it receives from other sources (the local 
network provider in particular). That PUBLISH would contain the xml 
document from the local network config server verbatim, which is never 
looked at by the UA. The UA receives in a NOTIFY and sends it to its 
main config server in a PUBLISH.

The nice thing is, in the simple (and much more common case) where there 
is no local config server, the PUBLISH behavior of multiple 
subscriptions evaporate, and the simple thing happens - one 
subscription, one document that comes in the notify, with one set of 
settings that gets used. This is in contrast to the current solution, 
which requires multiple subscriptions in all cases, and for every 
dataset definition and phone implementation to worry about merging day one.

I'll propose this at the mike in sipping shortly, but I wanted to post 
this to the list as well.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Aug 2005 03:49:37 -0400

Jonathan,

I too am concerned with the complexity of merging. But I'm not convinced 
one can avoid putting the burden on the UA. I see a couple of issues 
with what you propose below:

There aren't just two sources of config info - i believe there are four: 
local, device, AOR, application. I don't see clear dominance of one over 
another, so it isn't clear which one is best suited to do the merging. I 
don't think it can be the server for the AOR, because there could be 
multiple AORs. To do it that way the device would at least have to 
partition itself by AOR, and do the merge separately for each AOR. In 
that case I don't understand how the application profile fits in.

If one server is to be dominant for purposes of merging, then I think it 
is probably the one handling the device configuration, since it will 
probably be the one that determines which AORs the device supports.

	Paul