On 4/5/2010 8:00 AM, Scott Lawrence wrote: > 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). NOTHING can be "assumed about an IETF Standard which does not have an accompanying use model or BCP" for its use, so this is in fact relevant and appropriate. > >>> 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. But since you have not restricted them from doing this really stupid thing you cannot assume they wont. > >>> 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. Then why make any Assumptions about anything? 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 >
begin:vcard fn:Todd Glassey n:Glassey;Todd email;internet:TGlassey@xxxxxxxxxxxxx x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf