On Tue, 2009-08-18 at 08:25 -0400, Beeton, Carolyn (CAR:9D60) wrote: > > New Revision 16189 > <http://code.sipfoundry.org//changelog/sipXecs/?cs=16189> > > Committer dworley > > Date 2009-08-17 15:29:59 -0500 (Mon, 17 Aug 2009) > > > > Revise SipSubscribeClient::handleNotifyRequest so that a NOTIFY to a > > subscription with state SUBSCRIPTION_TERMINATED receives a 481 > > response. > > Do you think that is the correct thing to do on receipt of NOTIFY with > subscription-state=terminated? > > My reading of 3265 3.2.4 is that that is the normal way to end a > subscription (it is triggered by the subscriber sending SUBSCRIBE with > expires=0), and should not cause a 481. > > " If the "Subscription-State" value is "terminated", the subscriber > should consider the subscription terminated. The "expires" parameter > has no semantics for "terminated". If a reason code is present, the > client should behave as described below." > > and in 3.3.4 > > " A subscription is destroyed when a notifier sends a NOTIFY request > with a "Subscription-State" of "terminated". > > A subscriber may send a SUBSCRIBE request with an "Expires" header > of 0 in order to trigger the sending of such a NOTIFY request; > however, for the purposes of subscription and dialog lifetime, the > subscription is not considered terminated until the NOTIFY with a > "Subscription-State" of "terminated" is sent." > > It doesn't say explicitly what the proper response to a > NOTIFY(subscription-state=terminated) should be.
The trouble is that the defined behavior isn't particularly sensible -- the subscriber wants to be able to forget about a subscription once it has sent SUBSCRIBE with Expires: 0, but the RFC requires that it maintain information regarding subscriptions that it has attempted to terminate but for which it hasn't yet received terminating NOTIFYs. (And in theory, this information needs to be maintained indefinitely.) The current workaround is that when a NOTIFY is received for which SipSubscribeClient does not have subscription information, and Subscription-State is terminated, then SipSubscribeClient responds 200 (whereas it would ordinary respond 481). This makes the usual use-cases work as expected, and never prolongs a subscription that should not be prolonged. 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/
