[reSIProcate] handling recoverable failures in dum

[Jason Fischl <jason@xxxxxxxxxxxxxx>]

I had a conversation with Robert about failures and how they should be 
handled in dum. One type of failure is where a 408 is received or 
generated by the transaction layer. I think the dum layer should notify 
the application through some handler like onTimeout but that it should 
then proceed to retry the request again but force the transaction layer 
to redo the SRV lookups. This way, when the application says, 
startRegistering and at some point in the future it receives a 408 to a 
reREGISTER because the wireless network went off the air for 30 seconds 
it can recover without the application writer having to do anything 
special. If the app wants to react to the timeout by ending the usage, 
it can do so.

On a similar note, in a ClientSubscription, if it receives a 481 because 
the presence server restarted and lost all of its subscription dialogs, 
the ClientSubscription should automatically reSUBSCRIBE with a new 
dialog. The application doesn't need to be in the loop on this one. 

There's a bit of plumbing that will need to be done in dum to make this 
stuff work but it will make the jobs of the app writers much easier.

Comments?

Jason