> -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > 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) 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'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. -hadriel _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
