Subject: [Sip] Question regarding RFC 3265.

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Wed, 14 Jan 2004 17:12:13 -0800

Hi:

Per section 3.3.2 of RFC 3265, a NOTIFY request is considered failed if a response times out and that if the subscription was installed using soft-state (SUBSCRIBE), the notifier should remove the subscription. The reason for this being the subscriber could have crashed or disappeared for ever. 
While the above mentioned approach works well where the reasons provided in the RFC are the real reasons; it has an undesirable side effect in scenarios where a NOTIFY timesout due to a temporary network outage, an intermediate proxy crash, et al.  It results in a subscriber not getting status until such time he/she attempts to reSUBSCRIBE. Thus applications using the same like MWI, presence, dialog state break down until such period...... Wanted to know if this issue was considered??

Regards,
Venkatesh

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 14 Jan 2004 21:13:25 -0500

> Per section 3.3.2 of RFC 3265, a NOTIFY request 
> is considered failed if a response times out and 
> that if the subscription was installed using 
> soft-state (SUBSCRIBE), the notifier 
> should remove the subscription. The reason for this 
> being the subscriber could have crashed or disappeared 
> for ever. 
> While the above mentioned approach works well where the 
> reasons provided in the RFC are the real reasons; it has an 
> undesirable side effect in scenarios where a NOTIFY timesout 
> due to a temporary network outage, an intermediate proxy 
> crash, et al.  It results in a subscriber not getting status 
> until such time he/she attempts to reSUBSCRIBE. Thus 
> applications using the same like MWI, presence, dialog state 
> break down until such period...... Wanted to know if this 
> issue was considered??

Yes.  The same concept is associated with the 
session-timer and rfc3261; a 408 type situation
triggers the release of a call.

The strength is currently only a SHOULD.
If you want to avoid some customer
complaints, you might not want to apply
the SHOULD to every event package.
You potentially can satisfy
the "undue strain on a network" aspects
of 3.2.2 by allowing a 408 type situation
to trigger a temporary throttling mechanism 
instead of removing the subscription.