Hi Scott, Comments inline... > -----Original Message----- > From: Scott Lawrence [mailto:xmlscott@xxxxxxxxx] > Sent: Thursday, April 01, 2010 10:27 PM > To: Hadriel Kaplan > > If the UA is not behind a NAT, the cost of the subscription is a few > bytes of state in the configuration server. Well, it's not just a "few" bytes - it's a whole dialog's worth of state. (call-id, tags, To-URI, From-URI, list of routes, expires, whatever) But it's also the SIP signaling - every subscription expires interval the UA has to send a Subscribe to refresh, the server has to process it, update the subscription state, return a 200, send a Notify, and get a 200 for that. No? Obviously you could make the expiration interval long, but however long you make it will be as long as the worst-case config-change time, in case the Subscription server failed/restarted in-between. So that same time is also how long the polling interval could/would be if the UA just checked the HTTP server instead. > If the UA is behind a NAT... > [snipped text] Of course - I only mentioned the NAT issue because some folks had talked about the subscription going to a config-server directly without going through edge proxies. > 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. Of course telling users to reboot is untenable. I'm not suggesting they should. But the actual config data identified in the draft, and any I've seen in actual use, is not the kind that requires frequent updating. More to the point, some SSP's are perfectly fine with rolling out new "features" over the course of a day or X hours instead of this instant. They don't just switch over instantly anyway, and many SSP's require migration time and old-mode support for a period because they can't disrupt established calls. Regardless, my point isn't that it's not a nice feature to be able to do it instantly - my point is it's a nice feature, not a requirement for ua-configuration to work. Let the operator decide whether to do it. Don't mandate it be used. -hadriel p.s. and really instead of requiring permanent Subscriptions for every SIP mechanism which needs instant notification, we should just define a generic mechanism for asynchronous notification to UA's from their SSP for this and other uses. I know it needs some means for the UA to authenticate the request, but that's a good problem to solve. :) _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf