On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote: > > -----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. You assume that the configuration server looses subscription state on a restart... that would be a pretty shabby implementation, especially given that one would expect the subscription times to be very long (if I were going to make a suggestion, it would be at least a week). > > 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. Again, that would be very poor design on the part of the provider, and is entirely within the providers control since they are setting the URL value and all the DNS records that control routing for the domain in that URL. > > 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. Well, my experience is mostly in enterprise deployments (some quite large), but certainly in those people expect immediate response (certainly less than a minute) when they make a change. I think that as large scale service providers start to roll out better features like custom ring tones and fancy display features (which many of the current generation of SIP phones have, and which require configuration), they'll need similar responsiveness (or, put another way, the ones that provide immediate gratification will be perceived to be much higher quality those that don't). I've never seen a SIP phone reboot during a call when told to reconfigure by any of the existing mechanisms; I would be amazed to see one do it with this - but again, that's an implementation quality issue. > 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. One of the things that I personally fought very hard for in this specification was removing optional behavior and choices of any kind whenever possible. This is purely my own personal opinion, but I think that many IETF specs have fallen into the trap of getting consensus by making too many protocol features optional or having alternative ways of doing things. Simplicity is virtue, and conditional statements in specifications are sources of interoperability problems. If we were to adjust this spec to, for example, allow the configuration server to decide whether or not the UA had to subscribe, then some providers would decide to not bother, and some UAs would decide that since today they only cared about that one provider they wouldn't bother to implement (or test) that part of the spec. Pretty soon the feature is a real crap shoot and again SIP phones look flaky and hard to administer. I freely admit to being something of a zealot in trying to keep the specification simple, with as few choices for any party as possible, because that's the best way to reach universal interoperability. > 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. :) I'm quite supportive of that idea, although I'd suggest that the real need is for a standard mechanism to address a specific UA that is not related to the AOR of any user addresses it happens to also accept. The old Pingtel phones had that (a 'hidden' registration that used the phones MAC address as the local part of the SIP URI), and I've missed having it countless times. We've got hacks for this in our sipXecs system that Dale has described in an I-D, but a standard mechanism would be far better. Solving that general problem is beyond the scope of this, though. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf