-----Original Message-----
From: Cullen Jennings [mailto:fluffy(_at_)cisco(_dot_)com]
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf