SIP is robust in the Internet environment.

SIP still works in predictable ways when packets are lost, when routes fail, and when endpoints fall off the network.

SIP achieves some of this robustness through a design principle to fail to a known-safe condition. The idea is that any change to the system has to be maintained through periodic refreshment. If the authority for a change isn’t available to maintain the change, then it’s not around to correct the change when new conditions cause it to be wrong.

For example, a presence user could post a presence document that says “I’m driving”. Somewhere along that drive, the user goes into a parking garage, losing connection to the network. The user leaves his car and makes it into a movie theater without reconnecting. In a less-robust system, that user’s presence will be wrong for the next hour or so. A SIP based presence system will notice, after some time, that the user is no longer maintaining the presence document and will fall back to a known safe default, probably “I don’t know anything about this user’s presence right now.”

This SIP-based presence user’s published presence is “soft-state”. It is information (state) the user put into the system that will go away if the user doesn’t maintain it. Stated another way, the information will expire unless it is refreshed.

By contrast, the position of a typical simple light-switch is “hard-state”. If you flip it up, it will stay up, possibly forever. It will only change back to down when you (or some other user) explicitly comes back to manipulate it.

The soft-state concept is reused in many parts of the SIP protocol. Registrations expire. Subscriptions expire. Presence documents (or any other published SIP Event documents) expire. The time it takes to expire is negotiated between the element providing the state, usually an endpoint, and the element keeping the state, such as a registrar or presence server. That negotiation goes like this:

Handset: “Would you please send requests for me to this Contact for the next hour?”

Registrar: “Yes, I’ll hold onto this Contact for you, but I’ll only keep it for 5 minutes.”

When making that request, the handset’s user is also saying “If something unexpected happens, I’m willing for the state I’ve handed you to be wrong for up to an hour”. The server is replying “I’m only willing to let things be wrong for 5 minutes”.

This points out why the Registrar above cannot say “Yes, I’ll hold onto this Contact for you, and to save you some trouble, I’ll keep it active for a month”. The handset user is only willing for things to be wrong for an hour. Half a month from now, that handset might not even exist.

Once soft-state is accepted, it must be refreshed or it will be deleted. That means that before the negotiated time passes, the element placing the state into the system must return and say “please hold onto this state a little longer”. In SIP, this refresh also re-negotiates the next expiration time.

In the figure below, Phil subscribes to Robert, asking for an hour. Robert grants the subscription, but limits the expiration of the subscription (the soft-state) to 5 minutes. Four minutes into the subscription, Phil refreshes it, asking for another hour, but again getting another 5 minutes. This time Phil doesn’t refresh the subscription, letting it expire. Note that the total subscription time was 9 minutes, not 10. Phil’s second 5 minutes started at the point of negotiation, not when the first 5 ran out.

No related posts.