ietf
[Top] [All Lists]

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

2010-04-06 11:16:33


-----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)  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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>