> -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] > 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) > > 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 would think that a > subscribe could be done stateless on the SSP too given the usual state in > dialog information techniques. I don't know what you mean? How can the UAS send a Notify asynchronously without having stored the tags, call-id and path info of the subscription dialog, created by the UAC/Subscriber? You can't cookify them anywhere in the messaging, for example, because the UAS is the one sending the Notify sometime later. (I'm not referring to SBC's storing the dialog state - I'm talking about the config server) > I get how using a register to form an > implicit subscribe would reduce the traffic of the initial subscribe > formation and that might be a interesting optimization for someone to go > write a draft on. But why bother with a dialog at all?? The only answer I heard previously was: so the UA knows it's the config server, which it trusts. Well, if a shared secret is what we need, then the private gruu is that secret. -hadriel _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf