Hi Scott,
Comments inline...
-----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.
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf