ietf
[Top] [All Lists]

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

2010-04-02 11:06:06
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

<Prev in Thread] Current Thread [Next in Thread>