On Apr 6, 2010, at 10:16 AM, Hadriel Kaplan wrote:
-----Original Message-----
From: Cullen Jennings [mailto:fluffy(_at_)cisco(_dot_)com]
Sent: Tuesday, April 06, 2010 11:53 AM
To: Hadriel Kaplan
However,I did want to comment on the use cases for this. There are many
service providers that think it is important to be able to push a new
configuration to a UA "quickly" and the definition of quickly varies
widely. Imagine the case where someone is having problems getting their
fax to work and the SP wants to change the preferred codec from 729 to 711.
Now I realize you could do that by using an SBC that forced negation to
only 711 but that would reduce the flexibility of the system. Some
operators want to be able to change the config on the UA. I have talked to
some that seem fine with the idea that the UA would poll ever 24 hours or
that the end user user would need to power cycle the UA. I have talked to
others that think that is totally unacceptable and need to be able to
trigger something that causes the UA to get the new config in something
more like 30 seconds. Different folks have different ideas of how fast you
need to be able to update this however when you start talking about how
fast people would like to roll out fix to a security of DOS attack problem,
all the service providers I have talked to start talking about much faster
times than 24 hours.
Right, so what happens if the Subscription *is* the DoS attack? I'm not
saying this to be cute - we need a way to turn it off, and have it off to
start with (i.e., on reboot).
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
As you know, there were several painful "growing pains" in the past in large
subscriber domains with unforeseen UA behavior. Similar issues cropped up
again when reg-event Subscriptions started getting deployed.
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? I would think that a subscribe
could be done stateless on the SSP too given the usual state in dialog
information techniques. 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.
I'm sure there are some deployments where polling would be fine but there
are lots that don't find this acceptable.
Absolutely - different strokes for different folks. That doesn't mean
everyone should be forced to do it.
This conversation constantly confuses the issue of must implement vs must
deploy. Which one are you objecting to here.
-hadriel
Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf