RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

[Scott Lawrence <[e-mail]>]

On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:[e-mail]]
> > Sent: Tuesday, April 06, 2010 12:56 PM
> > To: Hadriel Kaplan
> > 
> > > No one has any empirical evidence or experience with what this thing
> > > will do to large subscriber domains. (and by large I mean multiple
> > > millions of UA's, which is the scale several SIP deployments are in now)
> > 
> > I'm aware of deployments with millions of UAs that use subscribe. Agree
> > there are growing points in scaling anything and everything
> 
> 
> Right, but they're doing it for reg-events and presence, after the
> Registration.  During an avalanche, for example, they're implicitly
> throttled by the effective registration rates.  This config framework
> is reversing it, having subscriptions before the registrations.  I'm
> not saying it's not do-able or won't work, I'm just saying we don't
> know. (and I'm saying it's not free, and some folks won't think it's
> worth the cost)

This draft says nothing at all about the ordering of the change notice
subscription vs any registration.

> > > If what we really want is something to force the UA to download a config
> > > *right now*, then do that explicitly.  Give each registered UA a "private"
> > >gruu, known only to the SSP and UA.  When you want to refresh the UA, send
> > > a PUBLISH to the gruu, telling it to refresh its config.  You can do that
> > > gruu statelessly on the SSP side, any number of ways.
> > 
> > I care more there is  a way to do it than how it is done but can you
> > explain how that is lighter weight than a subscribe? 
> 
> One way: when the UA Registers, have the Registrar construct a
> "private" gruu, for example using a hash of the registered contact
> with an unchanging key only known to the registrar. (so no extra state
> in registrar)  Send that gruu back in the Register response with a new
> param name defined in your spec.  The UA stores this private gruu, but
> cannot use it for anything but matching.  The SSP can send an
> out-of-dialog PUBLISH asynchronously, to that contact using the gruu,
> to tell the UA to go get the HTTP config again.
> 
> It's lighter weight because there's no subscription messaging, no
> permanent dialog state, and even the gruu is constructable and does
> not need to be stored by the SSP, only by the UA.
> [sarcasm=on] I don't know why the IETF keeps trying to put state into
> the middle instead of leaving it in the ends! :) [sarcasm=off]

I'd be open to a fully worked out proposal based on PUBLISH, but I
actually don't think that there are big savings over a SUBSCRIBE based
mechanism.   I don't buy the argument that the dialog state is
burdensome - it's a few hundred bytes at most (and much of that size is
under the control of the server).

I do have some problem with making the notification some kind of side
effect of the 'normal' registration.  REGISTER exists to map an AOR to
one or more Contacts.  The Configuration Service needs to be able to
address the change notice (whatever method carries it) to a specific UA,
_not_ to the AOR of some user registered to that UA.  If the UA is going
to REGISTER an AOR for itself that is distinct from that of any user
registered on it, then the whole thing starts to look a lot like a
SUBSCRIBE.   While we did not include text in the draft to suggest the
use of the SIP-Etag mechanism in draft-ietf-sipcore-subnot-etags, it
could be added to suppress the initial NOTIFY associated with the
subscription (and if it would help, I'd have no problem with putting
such text in).