Proposed behavior for SipSubscribeClient to allow automatic
re-creation of failed subscriptions:
When addSubscription is called, appropriate state is created for the
"subscription set". An out-of-dialog SUBSCRIBE is sent to the
specified URI. All received NOTIFYs establish state for a
subscription.
If the out-of-dialog SUBSCRIBE receives a failure response, and if no
NOTIFY is received for it before the retry interval, then the
out-of-dialog SUBSCRIBE is retried at increasing intervals (with new
Call-Id each time).
Each subscription is refreshed based on the expiration times given in
NOTIFY requests.
When a re-SUBSCRIBE receives a transient error response, it is retried
at increasing intervals. Transient errors are:
408
482
(To receive a 482 response, some other fork of the SUBSCRIBE must have
reached the UAS, presumably due to selecting an alternative
transport due to lost messages.)
When a re-SUBSCRIBE receives an error response that is not a transient
error response, we terminate all the subscriptions in the subscription
set and send a new out-of-dialog SUBSCRIBE.
Resend schedule:
initial resend interval: 1 second
doubling each time until
maximum resend interval: 5 minutes
Notifications to the upper layer:
The SipSubscribeClient machinery now sends notifications to its
application when subscriptions are created and when they end. These
will remain, and can be monitored by the application to determine
whether creating subscriptions was successful.
Forked subscriptions:
Although the SipSubscribeClient machinery can handle forked
subscriptions, in almost all of the cases we care about, there will be
only one UAS for each call of addSubscription. As a result, the
visible handling of failed subscriptions is much simpler than the
descriptions above: If the subscription fails, retry it.
If multiple subscriptions are generated, and one of them fails, it
appears to be a waste to terminate subscriptions that haven't failed.
But it significantly simplifies the logic to do so, and the new
SUBSCRIBE should reach any UASs whose subscriptions have not already
failed.
Comments?
Dale
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
