On Thu, 2010-04-01 at 14:59 -0400, Hadriel Kaplan wrote: > 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? You're not mis-reading the requirement. I'm not sure that I understand why you think that this is so expensive. If the UA is not behind a NAT, the cost of the subscription is a few bytes of state in the configuration server. If the UA is behind a NAT, then keepalives will be needed to permit any request (including an INVITE) to reach it. There is no need for separate keepalives for the SUBSCRIBE dialog and those needed to support the REGISTER pseudo-dialog. Since the service provider is in control of the routing for both INVITEs and those SUBSCRIBEs, surely it's trivial to arrange things so that the same keepalive is sufficient for both, which makes the marginal cost in the NAT case the same as that without a NAT. The avalanche restart problem already exists for the REGISTERs that will usually be coming at the same time, but the SUBSCRIBE already has (and the draft explicitly requires that that UA be prepared to use) mechanisms for telling the SUBSCRIBER to wait a server-specified time before retrying. Such a mechanism could be implemented at the SP edge without evening looking at the configuration data, and the UA is free to use its previous configuration in the mean time. So ... why? Many SIP features are implemented exclusively in or require close coordination with the capabilities of the UA. This means that changing such features often requires that the UA be reconfigured. In order to provide a good user experience, the time between a change request and when the change is in effect should be brief and predictable, which is inconsistent with long polling intervals. Telling users to reboot a device to activate a change or wait some unpredictable time are unsatisfactory. Having the configuration change notification mechanism allows the reconfiguration to be prompt and predictable. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf