On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote:
-----Original Message-----
From: Scott Lawrence [mailto:xmlscott(_at_)gmail(_dot_)com]
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf