On Tue, 2014-02-11 at 06:00 -0500, Brett Tate wrote: > Using "probation" and retry-after might produce the desired behavior. > It would basically allow obtaining approval/rejection during the > retry-after intervals. If they try after approval, it could be granted > or rejected.
So, in order to make this work, either the server would have to remember authorization for some period of time (indicated in retry-after); or the client would have to retry with non-zero Expires in hope that it will be enough to authorize the request, with explicit unsubscribe afterwards. This was a rather theoretical question; a more general one would be - if the subscriber receives a NOTIFY with Subscription-State: active or pending and 0 expires, should it consider the subscription terminated? State polling was one example I could come up with where the notifier could send such a NOTIFY (with pending state). The actual problem I'm dealing with is of even wider scope. Our existing code was relying on receiving NOTIFY with Subscription-State: terminated to terminate subscriptions, which resulted in memory leaks if the final NOTIFY is lost on the network or is never sent, and I'm trying to plug those leaks. It turns out it is incredibly hard to do without being able to order incoming NOTIFY requests wrt outgoing SUBSCRIBE, at the same time adhering to RFC 6665 Section 4.1.2.2. §3. Thanks, Jānis _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
