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

[Cullen Jennings <[e-mail]>]

On Apr 6, 2010, at 16:47 , Bernard Aboba wrote:

> Hadriel Kaplan said:
>  
> “Howdy, 
> This may not be within the normal rules of etiquette, but I will re-iterate my issues with this draft which I raised when it was discussed in RAI. 
>  
> 1) The mechanism does not scale, for large SSP's. (is this only meant for small deployments?)  
>  
> Expecting every UA to keep a permanent SIP Subscription to "config change" servers is unreasonable. Either the UA makes this Subscription directly to the Server(s), in which case there will be a large volume of keep-alives just to keep NAT pinholes alive; or it makes it through edge proxies, in which case it's a lot of SIP messaging both in the sense of keeping the Subscribe dialog alive but more importantly at the worst possible time: during avalanche restarts. Either way, it's not good. 
>  
> All this state and signaling is to achieve what? So that once a year or so we can tell UA's to do another HTTP Get so they change one of their config settings, or upgrade their firmware?? How is that cost-burden justified? Do most other applications keep permanent connections for such changes? Not as far as I can tell. They poll on a (very) infrequent interval. 
>  
> 2) I would be ok with (1) if it was optional, so only providers that wanted it had to pay for it, but as far as I can tell the mechanism *requires* implementation of this SIP Subscription service. Maybe I'm reading it wrong? Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP URI, and if the Subscription attempt fails then it has to start again, etc. Seems to me you're requiring/mandating a "nice-to-have-feature", and an expensive and complicated one at that. Why? 
>  
> -hadriel ”
>  
> [BA] I agree with your assessment.  This is one of those situations where (infrequent) polling scales better.   That is how currently most OS update mechanisms work;  they poll the update servers at intervals orders of magnitude longer than NAT refresh times (e.g. weekly or daily at most), with randomized polling times.  That way there is no need to maintain NAT bindings, and no danger of “flash crowds”.   Yes, it might take a while to bring all the clients up to the latest version, but if you’ve got any substantial client population, then you need to spread out the updates anyway to control the load on the update servers.
>  

So there are somethings like upgrading the software firmware on phones where a slow roll over makes sense, however there are other things like moving from a 4 digit to 5 digit internal dialing plan where you want to flash cut over all the phones at a given site. Can you imagine telling a site, uh, your phone will switch from 4 to 5 digit dialing some time in the next few days - if 4 digit stops working, try 5 digits and see if that works. That the sort of think that generates support calls that are far more expensive than servers. I realize that if you put the poll rate low enough, polling can achieve the same as notification but the rates required for many services make notification scale better than polling. 


> In my experience, even where NOTIFY is used to provide update notifications today, SUBSCRIBE is not.   Yes, that is non-standard, but I think it demonstrates concern about the overhead relating to SIP subscription/refresh. 
> __

Having dealt with many or the problems that come from setting MWI lights using NOTIFY without subscribe I am fairly confident that this NOTify without SUBscribe is broken is some many ways it is not even worth discussing.